Hi, Nikita, On Oct 31, Nikita Malyavin wrote:
On Mon, 31 Oct 2022 at 14:08, Sergei Golubchik <serg@mariadb.org> wrote:
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.
Yes, replication didn't support those cases. It didn't look like users care, though.
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?
Yes, it appears to be created in Table_map_log_event and removed on commit. That is, it survives multiple row events. Still, there are only two possibilities: * the table has a PK - then row format doesn't matter, just use a PK * the table has no PK - then row format doesn't matter, row pre-image will be always FULL So, you're right that in the replication case it's also enough to calculate the best key once, store it in RPL_TABLE_LIST, and not recalculate it per event. But even then it doesn't need a complex cache, but just one uint key_to_use; in RPL_TABLE_LIST. You only need some complex logic if the table has PK on the master, row image is not FULL, and you cannot use this PK on the slave. This use case wasn't supported before, it's not needed for online alter, so I suggest we won't try to do it together with already big and complex online alter task. Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org