Hi! On Sun, 30 Oct 2022 at 18:20, Sergei Golubchik <s...@mariadb.org> 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
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
