List:Commits« Previous MessageNext Message »
From:Jorgen Loland Date:May 5 2011 7:26am
Subject:Re: bzr commit into mysql-trunk branch (olav.sandstaa:3368) Bug#12321461
View as plain text  
Thank you for the explanation. Patch approved.

On 05/05/2011 09:23 AM, Olav Sandstaa wrote:
> On 05/05/2011 09:06, Jorgen Loland wrote:
>> Olav,
>>
>> Thank you for the new patch. I have one question before approving.
>>
>> On 05/04/2011 03:24 PM, Olav Sandstaa wrote:
>>> @@ -4869,7 +4869,26 @@ int DsMrr_impl::dsmrr_init(handler *h_ar
>>> /*
>>> We get here when the access alternates betwen MRR scan(s) and non-MRR
>>> scans.
>>> + */
>>>
>>> + /*
>>> + Verify consistency between the two handler objects:
>>> + 1. The main handler should either use the primary key or not have an
>>> + active index at this point since the clone handler (h2) is used for
>>> + reading the index.
>>> + 2. The index used for ICP should be the same for the two handlers or
>>> + it should not be set on the clone handler (h2).
>>> + 3. The ICP function should be the same for the two handlers or it should
>>> + not be set for the clone handler (h2).
>>
>> In which case(s) will h but not h2 have a pushed index after the cloning has
>> been done?
>
> I think this can happen in the following situation:
>
> a. The optimizer decides to use index X for retrieving data and we push down an
> index condition to the handler for index X.
> (at this point the pushed index is on handler h but not on h2 (since it has not
> been created yet).
>
> b. During the start of execution the server "changes its mind" about which index
> to use (in test_if_skip_sort_order()). So now we will use index Y for retrieving
> data.
>
> c. The scan is started on index Y that will use MRR. This will initialize the
> DsMRR object and create the h2 handler object. Since the index for this scan is
> Y we will not copy information about the pushed index condition from h to h2 in
> this situation.
>
> The code in DsMrr_impl::dsmrr_init() that does the copying from h to h2 is the
> following lines
>
> uint mrr_keyno= h->active_index;
>
> /* removed some lines... */
>
> if (mrr_keyno == h->pushed_idx_cond_keyno)
> pushed_cond= h->pushed_idx_cond;
>
> /* removed some more lines...*/
>
> if (pushed_cond)
> h2->idx_cond_push(mrr_keyno, pushed_cond);
>
> I have not actually verified this by tracing this code now but I think that this
> situation might happen as I described above. Let me know if you want me to look
> into it in more details to verify that my understanding is correct.
>
> Olav
>
>

-- 
Jørgen Løland | Senior Software Engineer | +47 73842138
Oracle MySQL
Trondheim, Norway
Thread
bzr commit into mysql-trunk branch (olav.sandstaa:3368) Bug#12321461Olav Sandstaa4 May
  • Re: bzr commit into mysql-trunk branch (olav.sandstaa:3368) Bug#12321461Jorgen Loland5 May
    • Re: bzr commit into mysql-trunk branch (olav.sandstaa:3368) Bug#12321461Olav Sandstaa5 May
      • Re: bzr commit into mysql-trunk branch (olav.sandstaa:3368) Bug#12321461Jorgen Loland5 May