maria-developers team mailing list archive

[Nikita Malyavin <nikitamalyavin@xxxxxxxxx>]

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