maria-developers team mailing list archive

[Nikita Malyavin <nikitamalyavin@xxxxxxxxx>]

Hi!

On Sun, 30 Oct 2022 at 18:20, Sergei Golubchik <serg@xxxxxxxxxxx> wrote:

> still, you didn't use `f == f->table->next_number_field`
> but we concluded it's safe, didn't we?
>
>
Yes, I just think I only fixed it in the last commit "improve DEFAULT
rules" (13222947)



> Also, I've looked at your latest branch. What were you optimizing with
> the commit 3afa3288221 (the one with usable_keys_data)?
>
> It's complex and I don't quite see what's the purpose of it.
> It looks like all you need to do is to decide on the best index to
> use, once, save it somewhere, e.g. in RPL_TABLE_LIST, and that's it.
>

Yes, and I do it that way, just few details:
* There was no way to access  RPL_TABLE_LIST in find_key directly,
 Rpl_table_data was used for that. Maybe we should return
  RPL_TABLE_LIST directly everywhere, as I had found no example where
  RPL_TABLE_LIST is unavailable. 0e04e82463 is made for that purpose.
* I didn't want to allocate memory as soon as replication is started.
 What if there are only write_row events? So it is done lazily.
* Sometimes the key set can change, if row_format was changed.
  So it needs to be recalculated


> This can be done, for example, in copy_data_between_tables().
>
For ONLINE ALTER TABLE yes, but what about usual replication? I'd prefer one
generic algorithm for everything.

-- 
Yours truly,
Nikita Malyavin