Hi, Georgi!
On Nov 11, Georgi Kodinov wrote:
> Serg,
>
> On 11.11.2008, at 18:09, Sergei Golubchik wrote:
>
>>> When the storage engine uses secondary keys clustered with the
>>> primary key MySQL was adding the primary key parts to each secondary
>>> key. In doing so it was not checking whether the index was on full
>>> columns and this resulted in the secondary keys being added to the
>>> list of covering keys even if they have partial columns. Fixed by
>>> cleaning up the list of covering keys if the primary key has a
>>> partial column as a key part.
>>
>> Could you explain please where was a bug, in the code ? What functions
>> and lines were making wrong assumptions and switching keyread mode for
>> partial keys ?
>
> Sure. All the keys in the keys_for_keyread (that's later assigned to
> covering_keys) are considered covering, i.e. no read from the main table
> was necessary. The fact that a key is in the covering_keys bitmap is a good
> enough justification to consider it a covering key. No additional checks
> are made if the key is a covering one.
> This information is used in several places : e.g.
> SQL_SEELCT::test_quick_select, get_best_group_min_max, best_access_path,
> make_join_readinfo etc.
> The actual switching to key_read is done in make_join_readinfo,
> join_read_const_table, join_read_first, join_read_last etc.
Yes, that much I know. I asked what code was enabling keyread for
partial keys. As you can see, in open_binary_frm() partial keys are
*not* added to keys_for_keyread bitmap. So, how comes that a keyread is
enabled for a key not present in keys_for_keyread ?
Regards / Mit vielen Grüßen,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ Principal Software Engineer/Server Architect
/_/ /_/\_, /___/\___\_\___/ Sun Microsystems GmbH, HRB München 161028
<___/ Sonnenallee 1, 85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Häring
