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@mariadb.org> 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@mariadb.org