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
>> + */
>> + /*
>> + 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)
/* removed some more lines...*/
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.