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:
>> 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
>>> + */
>>> + /*
>>> + 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
> 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.
Jørgen Løland | Senior Software Engineer | +47 73842138