maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Nikita,

On Nov 01, Nikita Malyavin wrote:
> 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..

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 security@xxxxxxxxxxx