← Back to team overview

maria-developers team mailing list archive

Re: Fwd: [Commits] Rev 2901: BNLH algorithm always used a full table scan over the joined table in file:///home/igor/maria/maria-5.3-mwl128-hashrange/

 

Hello Igor,

Here's the promised proof of deadcode:

On Fri, Feb 11, 2011 at 08:49:37PM -0800, Igor Babaev wrote:
> === modified file 'sql/sql_select.cc'
> --- a/sql/sql_select.cc	2011-02-06 04:57:03 +0000
> +++ b/sql/sql_select.cc	2011-02-12 04:41:22 +0000
> @@ -8419,6 +8438,11 @@
>            sort_by_tab->type= JT_ALL;
>            sort_by_tab->read_first_record= join_init_read_record;
>          }
> +        else if (sort_by_tab->type == JT_HASH_NEXT)
> +        {
> +          sort_by_tab->type= JT_HASH;
> +          sort_by_tab->read_first_record= join_init_read_record;
> +        }
>        }
>        break;
>      }

Statement: the above else-if branch can never be taken, i.e. equality

   sort_by_tab->type == JT_HASH_NEXT       (1)

can never be true.

Proof: 
First, let's see what JOIN_TABs can be in sort_by_tab. sort_by_tab is assigned in this statement:

       JOIN_TAB *sort_by_tab= join->group && join->simple_group &&
                              join->group_list ?
                               join->join_tab+join->const_tables :
                               join->get_sort_by_join_tab();

i.e. possible values are
  1.  join->join_tab+join->const_tables
  2.  join->get_sort_by_join_tab()

get_sort_by_join_tab is defined in sql_select.h as:

  JOIN_TAB *get_sort_by_join_tab()
  {
    return (need_tmp || !sort_by_table || skip_sort_order ||
            ((group || tmp_table_param.sum_func_count) && !group_list)) ?
              NULL : join_tab+const_tables;
  }

i.e. it can return:
  1. NULL (which is not interesting)
  2. join->join_tab + const_tables.

this draws us to conclusion that sort_by_tab can be
 - NULL 
 - join->join_tab + const_tables.

so equality (1) can be rewritten as 
   
   join->join_tab[const_tables].type == JT_HASH_NEXT   (2)

Now, let's explore the question, what join_tab elements can have type==JT_HASH_NEXT. The value JT_HASH_NEXT
is assigned in only one place:

  sql_select.cc|8399| tab->type= tab->type == JT_ALL ? JT_NEXT : JT_HASH_NEXT;

this line is inside the case block of code:
     
      break;
    case JT_ALL:
    case JT_HASH:
       ....
         tab->type= tab->type == JT_ALL ? JT_NEXT : JT_HASH_NEXT;

which means that tab->type can become JT_HASH_NEXT only if it was JT_HASH before.

Let's see when a join_tab can get type==JT_HASH. There's only one assignment that can assign type=JT_HASH.
It is at sql_select.cc:8279 :

    if (tab->cache && tab->cache->get_join_alg() == JOIN_CACHE::BNLH_JOIN_ALG)
      tab->type= JT_HASH;

i.e. tab->type can become JT_HASH only if tab->cache!=NULL.  tab->cache can be set to non-NULL value only inside
check_join_cache_usage(). However, the first lines in check_join_cache_usage() have this code:

 
  uint i= tab - join->join_tab;

  join->return_tab= 0;

  if (cache_level == 0 || i == join->const_tables || !prev_tab)
    return 0;

from which we can conclude that 

  join->join_tab[join->const_tables].cache == NULL 

will always hold. Going back on our chain of reasoning, we get that

  join->join_tab[join->const_tables].cache == NULL   at all times=>
  join->join_tab[join->const_tables].type != JT_HASH  at all times  =>
  join->join_tab[join->const_tables].type != JT_HASH_NEXT  at all times  =>
   equality (2) is false always => original equality (1) is false always,  q.e.d.




BR
 Sergey
-- 
Sergey Petrunia, Software Developer
Monty Program AB, http://askmonty.org
Blog: http://s.petrunia.net/blog