List:Commits« Previous MessageNext Message »
From:Roy Lyseng Date:June 16 2011 9:25am
Subject:Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200
View as plain text  
On 16.06.11 11.21, Øystein Grøvlen wrote:
> On 16/06/2011 10:48, Roy Lyseng wrote:
>> On 16.06.11 10.03, Øystein Grøvlen wrote:
>>> On 15/06/2011 15:57, Roy Lyseng wrote:
>>>> #At file:///home/rl136806/mysql/repo/mysql-work0/ based on
>>>> revid:jorgen.loland@stripped
>>>>
>>>> 3385 Roy Lyseng 2011-06-15
>>>> Bug#12603200: Assert in QUICK_INDEX_MERGE_SELECT::need_sorted_output
>>>>
>>>> The problematic query is semi-join transformed and a LooseScan
>>>> strategy is selected. setup_semijoin_dups_elimination() inspects
>>>> the provided quick select object and attempts to set it to require
>>>> ordering of output rows. However, the quick select object was not
>>>> selected in the first place (see
>>>> Loose_scan_opt::check_ref_access_part1()), hence there is a missing
>>>> check that the index covered by the quick select matches the index
>>>> selected for the loose scan access.
>>>>
>>>> Fixed by adding this check, and also deleting the quick select object
>>>> if it was not chosen for accessing this table.
>>>
>>> Hi,
>>>
>>> Did you consider deleting the quick select object at the point where
>>> it is
>>> decided to not use it?
>>
>> IMHO this is the place where the decision is taken. Do you have another
>> view?
>>
>
> You say in it the commit comments that the quick select object was not selected
> in Loose_scan_opt::check_ref_access_part1(). Sounds to me like that is where the
> decision is made. Maybe that is where the need_sorted_output call should have
> been put in the first place.

Loose_scan_opt::check_ref_access_part1( is called from best_access_part() which 
explores potential uses of various access methods. The quick object might be 
used in a different context later, so it would be wrong to delete it at this 
stage. setup_semijoin_dups_elimination() is called from make_join_readinfo() 
which finalizes the plan after the optimal order has been chosen, so I think 
this is the right place to either select or discard the quick object.

Thanks,
Roy
Thread
bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Roy Lyseng16 Jun
  • Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Øystein Grøvlen16 Jun
    • Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Roy Lyseng16 Jun
      • Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Øystein Grøvlen16 Jun
        • Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Roy Lyseng16 Jun
          • Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Øystein Grøvlen16 Jun
  • Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Øystein Grøvlen19 Jun
    • Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Roy Lyseng21 Jun
  • Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Jorgen Loland20 Jun
Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Roy Lyseng16 Jun
  • Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Øystein Grøvlen16 Jun
    • Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Martin Hansson27 Jun
      • Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Jorgen Loland28 Jun
        • Re: bzr commit into mysql-trunk branch (roy.lyseng:3385) Bug#12603200Jorgen Loland28 Jun