Re: [Maria-developers] 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
participants (1)
-
Sergey Petrunya