List:Commits« Previous MessageNext Message »
From:Jørgen Løland Date:June 16 2010 11:18am
Subject:Re: bzr commit into mysql-5.4 branch (epotemkin:2814) Bug#45174
View as plain text  
Sergey Petrunya wrote:
> Hi!
> 
> I can't offer any testcases but I think this patch has several issues. See
> below.
(...)
>> +    */
>> +    while ((item= it++))
>> +    {
>> +      field_tab= item->field->table->reginfo.join_tab;
>> +      if (!(field_tab->sj_strategy == SJ_OPT_MATERIALIZE ||
>> +            field_tab->sj_strategy == SJ_OPT_MATERIALIZE_SCAN))
> This is a wrong way to check if a field is inside SJ-Materialization nest. The
> condition is true only for the first table in SJ-Materialization nest, while we
> need to catch *any* SJ-Mat-inner table. 
> 
> the correct way to check this is as follows:
> 
>   field_tab->pos_in_table_list->embedding &&
>   field_tab->pos_in_table_list->embedding->sj_mat &&
>   field_tab->pos_in_table_list->embedding->sj_mat->is_used
> 

Sergey's way of checking if the table is inside a SJM nest, together with this 
rewrite of the following for-look:

     /*
       It's a field from an materialized semi-join. We can substitute it only
       for a field from the same semi-join.
     */
     JOIN_TAB *first;
     JOIN *join= field_tab->join;
     uint tab_idx= field_tab - field_tab->join->join_tab;
     /* Find first table of this semi-join. */
     for (int i=tab_idx; i >= join->const_tables; i--)
     {
       if (join->best_positions[i].sj_strategy == SJ_OPT_MATERIALIZE_LOOKUP ||
           join->best_positions[i].sj_strategy == SJ_OPT_MATERIALIZE_SCAN)
       {
         //We have found the first table inside this semi-join nest
         first= join->join_tab + i;
         break;
       }
     }

fixes BUG#50019 as well. Note that

     for (int i=tab_idx; i >= join->const_tables; i--) {}

does not stop when i gets below 0 if const_tables == 0. You'll probably have to 
cast join->const_tables to int or even better: change the type of const_tables 
to int since we're unlikely to encounter that many tables anyway ;)

I suggest BUG#50019 should be fixed as part of this bug and be closed as a 
duplicate.

-- 
Jørgen Løland
Thread
bzr commit into mysql-5.4 branch (epotemkin:2814) Bug#45174Evgeny Potemkin13 Oct
  • Re: bzr commit into mysql-5.4 branch (epotemkin:2814) Bug#45174Guilhem Bichot22 Oct
    • Re: bzr commit into mysql-5.4 branch (epotemkin:2814) Bug#45174Evgeny Potemkin22 Oct
  • Re: bzr commit into mysql-5.4 branch (epotemkin:2814) Bug#45174Guilhem Bichot24 Oct
    • Re: bzr commit into mysql-5.4 branch (epotemkin:2814) Bug#45174Evgeny Potemkin5 Nov
      • Re: bzr commit into mysql-5.4 branch (epotemkin:2814) Bug#45174Guilhem Bichot5 Nov
        • Re: bzr commit into mysql-5.4 branch (epotemkin:2814) Bug#45174Evgeny Potemkin5 Nov
  • Re: bzr commit into mysql-5.4 branch (epotemkin:2814) Bug#45174Sergey Petrunya13 Mar
    • Re: bzr commit into mysql-5.4 branch (epotemkin:2814) Bug#45174Jørgen Løland16 Jun
      • Re: bzr commit into mysql-5.4 branch (epotemkin:2814) Bug#45174Roy Lyseng16 Jun