maria-developers team mailing list archive

[Nikita Malyavin <nikitamalyavin@xxxxxxxxx>]

Hi Sergei!

I traced out the problem I faced with refs comparison -- It's in key_copy
implementation, which uses field->get_key_image, which in turn copied data
to the buffer passed, but from `field->ptr`. The latter is important -- it
means, current key_copy implementation always copies data from
table->record[0].

I have already came across it while implementing FKs, and have fixed the
implementation in the separate commit (see key_copy: use from_record
argument to copy the data from). That fixes 'innodb' test combination.

I think now everything you wanted so far is in the branch, so am waiting
now for your comments on the new code!

Kind regards,
Nikita Malyavin

On Thu, 5 Dec 2019 at 02:36, Sergei Golubchik <serg@xxxxxxxxxxx> wrote:

> Hi, Nikita!
>
> On Dec 05, Nikita Malyavin wrote:
> > Heh, unfortunately comparing refs will not work in conjunction with
> KEYREAD:
> >
> > for innodb ref can be a primary key, if it has it, so index is not
> > clustered. The index we're evaluating can be different from a primary
> key.
> >
> > In that case some values can be left unfetched with KEYREAD.
> >
> > All that is because if innodb has primary key, it just does key_copy
>
> In InnoDB every secondary key automatically has primary key at the
> end, because after finding the key value in a secondary index,
> InnoDB needs to fetch the corresponding row, so it has to know the PK
> value for that secondary key.
>
> Generalizing, every secondary key has to have the "ref" for the
> corresponding row. In InnoDB it's PK, in MyISAM it's the row offset, in
> MEMORY it's pointer. But either way, in any engine, any secondary key
> knows the ref for the corresponding row.
>
> Regards,
> Sergei
> VP of MariaDB Server Engineering
> and security@xxxxxxxxxxx