We've also had MDEV-19082 <https://jira.mariadb.org/browse/MDEV-19082> -- change application-time period tables to use HA_EXTRA_REMEMBER_POS. On Fri, 6 Dec 2019 at 18:33, Nikita Malyavin <nikitamalyavin@gmail.com> wrote:
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
-- Yours truly, Nikita Malyavin