Hi, Nikita,
On Oct 31, Nikita Malyavin wrote:
>
> > 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.
>
> > 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.
For replication it already works.
It didn't work for cases with extra columns, when master a primary key,
or some other key was amended with an extra column, for example.
Or when the set of keys has been changed some other way.
The key is found once, before a batch
of rows. It cannot be done less often than that, because the next row
event can be for a different table and have a different row format.
I hope RPL_TABLE_LIST can be preserved between the events. Is it so?