← Back to team overview

maria-developers team mailing list archive

Re: 52f489ebccb: MDEV-29069 follow-up: support partially suitable keys


On Mon, 31 Oct 2022 at 21:22, Sergei Golubchik <serg@xxxxxxxxxxx> 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

> 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;

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,
Let me simplify that

Yours truly,
Nikita Malyavin

Follow ups