Hi!
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