Thank you for your reply.
My strategy for answering this question was to look for all places
where the optimizer checks if the primary key is clustered, and see if
a generalization needs to be done for all keys. I am still working on
that part, and maybe the strategy of replacing
"primary_key_is_clustered" with table->file->index_flags(nr) &
HA_CLUSTERED_KEY would help solve the problems.
What concerns me is if there are places where there is the assumption
that there is ONLY ONE clustered key. I think this may be what is
going on with the code that determines to use an index_merge (I sent
an email about this on June 23rd to internals).
On Fri, Jul 3, 2009 at 9:22 AM, Sergei Golubchik<serg@stripped> wrote:
> Hi, Zardosht!
> On Jun 18, Zardosht Kasheff wrote:
>> What I am trying to figure out is what changes need to be done to the
>> query optimizer to properly support this feature.
>> Here is my failed attempt at answer the question:
>> I looked at places where handler::primary_key_is_clustered is called.
>> I figured that if there are locations where the optimizer needs to
>> know if the primary key is clustered, they may also be places where
>> the optimizer needs to know if another key is clustered. I only saw
>> one potential location where this might be necessary:
>> in sql_select.cc, in function test_if_skip_sort_order,
>> we have : bool is_covering=
> table->covering_keys.is_set(nr) ||
> nr == table->s->primary_key &&
>> I figure that this will also need to take into account if the key is
>> clustered, correct?
> Yes. I'd generalize the above as
> bool is_covering= table->covering_keys.is_set(nr) ||
> table->file->index_flags(nr) & HA_CLUSTERED_KEY;
> alternatively, we could simply initialize table->covering_keys bitmap to
> include all clustered keys. This should be even better, I suppose - it
> will cover more code paths in the optimizer, not only
>> So, in conclusion, given everything above, I have one general question
>> and one specific question.
>> The general question: can anyone think of any other place where the
>> optimizer needs to be tweaked to be aware of clustered keys?
> I think yes.
> In partitioning, in mrr (DsMrr_impl::choose_mrr_impl), in many places in
> the range optimizer.
> Simple grep for the word 'clustered' returns lots of matches :(
>> The specific question: does any tweaking need to happen in
> Yes, see above.
> Regards / Mit vielen Grüßen,
> __ ___ ___ ____ __
> / |/ /_ __/ __/ __ \/ / Sergei Golubchik
> / /|_/ / // /\ \/ /_/ / /__ Principal Software Engineer/Server Architect
> /_/ /_/\_, /___/\___\_\___/ Sun Microsystems GmbH, HRB München
> Sonnenallee 1, 85551 Kirchheim-Heimstetten
> Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
> Vorsitzender des Aufsichtsrates: Martin Häring
|• Re: query optimization and multiple clustering keys||Zardosht Kasheff||3 Jul|