← Back to team overview

maria-developers team mailing list archive

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