maria-developers team mailing list archive
-
maria-developers team
-
Mailing list archive
-
Message #03683
On possible bug in get_partial_join_cost()
Hi Timour,
Answers to irc questions:
<timour> spetrunia, I found a problem in get_partial_join_cost(), could you please look at this:
<timour> for (uint i= join->const_tables; i < n_tables + join->const_tables ; i++)
<timour> spetrunia, why "i < n_tables + join->const_tables" ? isn't the number
of tables always the same?
<timour> That is, shouldn't we just skip the constant tables assuming they are
in the beginning of join->best_positions ?
Yes we should skip the constant tables, and they are at the beginning of
best_positions.
The number of tables passed as n_tables varies across different invocations of
get_partial_join_cost():
uint n_tables= my_count_bits(sj_nest->sj_inner_tables & ~join->const_table_map);
SJ_MATERIALIZATION_INFO* sjm;
if (!(sjm= new SJ_MATERIALIZATION_INFO) ||
!(sjm->positions= (POSITION*)join->thd->alloc(sizeof(POSITION)*
n_tables)))
DBUG_RETURN(TRUE); /* purecov: inspected */
sjm->tables= n_tables;
sjm->is_used= FALSE;
double subjoin_out_rows, subjoin_read_time;
get_partial_join_cost(join, n_tables,
&subjoin_read_time, &subjoin_out_rows);
Here one can see that n_tables is "number of non-constant tables within an
SJ-Materialization nest". Different nests will contain different numbers of
tables.
<timour> spetrunia, I changed the loop upper boundary to n_tables, then I get
few improved EXPLAINS, and got a crash, then I had to leave.
I think the change is wrong: if you stop at n_tables, that means that
partial_join_cost() has done optimization for the first
(n_tables - join->const_tables)
non-constant tables, which is not right. If you need further help, could you
give a concrete example that causes the problem?
BR
Sergey
--
Sergey Petrunia, Software Developer
Monty Program AB, http://askmonty.org
Blog: http://s.petrunia.net/blog