Hi, Nikita, On Nov 01, Nikita Malyavin wrote: > 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..
Not quite. If there is no PK, we should use the key with the highest cardinality. > > 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? Doesn't matter, see above. If the table had PK, then simpy use PK, even if ROW_FORMAT changes. If the table had no PK, then binlog will always have the full row, no matter how you'll be changing ROW_FORMAT. Regards, Sergei VP of MariaDB Server Engineering and secur...@mariadb.org _______________________________________________ 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
