← Back to team overview

maria-developers team mailing list archive

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

 

Hi, Nikita,

On Oct 31, Nikita Malyavin wrote:
> On Mon, 31 Oct 2022 at 14:08, Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
> > On Oct 31, Nikita Malyavin wrote:
> > >
> > > > Also, I've looked at your latest branch. What were you
> > > > optimizing with the commit 3afa3288221 (the one with
> > > > usable_keys_data)?
> > > >
> > > > It's complex and I don't quite see what's the purpose of it. It
> > > > looks like all you need to do is to decide on the best index to
> > > > use, once, save it somewhere, e.g. in RPL_TABLE_LIST, and that's
> > > > it.
> > >
> > > > This can be done, for example, in copy_data_between_tables().
> > > >
> > > For ONLINE ALTER TABLE yes, but what about usual replication? I'd
> > > prefer one generic algorithm for everything.
> >
> > For replication it already works.
> 
> It didn't work for cases with extra columns, when master a primary
> key, or some other key was amended with an extra column, for example.
> Or when the set of keys has been changed some other way.

Yes, replication didn't support those cases. It didn't look like users
care, though.

> > The key is found once, before a batch of rows. It cannot be done
> > less often than that, because the next row event can be for a
> > different table and have a different row format.
>
> 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

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.

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.

Regards,
Sergei
VP of MariaDB Server Engineering
and security@xxxxxxxxxxx


Follow ups

References