maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #03961
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