On Mon, 31 Oct 2022 at 21:22, Sergei Golubchik <s...@mariadb.org> wrote:
> > 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 > Sooo we can always just use the first key we have, assuming PK always comes first.. > 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. > Agree, one key is enough to store. I also wanted to ask: -- What if ROW_FORMAT was changed in between of a transaction? But I think we don't care for now, as we're gonna assume taht salve keys are not being changed and always match master's schema. > 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. > By complex logic, do you mean all that bitmap comparison I made? Then yes, agree. Let me simplify that -- 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