> 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