In the function JOIN::create_postjoin_aggr_table in sql_select.cc, the tmp_table_param field is not updated by the new values of the tab->tmp_table_param.
the tab->tmp_table_param is updated here, but these are not updated in join->tmp_table_param.
Varun Gupta (Inactive)
added a comment - In the function JOIN::create_postjoin_aggr_table in sql_select.cc, the tmp_table_param field is not updated by the new values of the tab->tmp_table_param.
TABLE* table= create_tmp_table(thd, tab->tmp_table_param, *table_fields,
table_group, distinct,
save_sum_fields, select_options, table_rows_limit,
"" , true , keep_row_order);
the tab->tmp_table_param is updated here, but these are not updated in join->tmp_table_param.
The first one seems to be used at optimization stage for storing various
global parameters (like tmp_table_param.precomputed_group_by).
The second one was introduced in 10.2. It is there to provide "new" handling
for cases where the JOIN is executed using multiple temporary tables.
(I dont fully understand the "old" way but it involved temporary "dummy"
JOIN objects, etc. The new way is have JOIN_TABs for operations that write
to temporary tables)
So, looking at what JOIN::create_postjoin_aggr_table does.
Copy JOIN::tmp_table_param into JOIN_TAB::tmp_table_param:
tab->tmp_table_param= new TMP_TABLE_PARAM(tmp_table_param);
if (join->rollup_write_data((uint) (idx+1), table))
DBUG_RETURN(NESTED_LOOP_ERROR);
}
So I guess it's better if rollup_write_data used join_tab->tmp_table_param, just like create_internal_tmp_table_from_heap call above does.
Sergei Petrunia
added a comment - Looking at the relevant code.
There are two TMP_TABLE_PARAM objects:
1. join->tmp_table_param
2. join->join_tab [N] ->tmp_table_param
The first one seems to be used at optimization stage for storing various
global parameters (like tmp_table_param.precomputed_group_by).
The second one was introduced in 10.2. It is there to provide "new" handling
for cases where the JOIN is executed using multiple temporary tables.
(I dont fully understand the "old" way but it involved temporary "dummy"
JOIN objects, etc. The new way is have JOIN_TABs for operations that write
to temporary tables)
So, looking at what JOIN::create_postjoin_aggr_table does.
Copy JOIN::tmp_table_param into JOIN_TAB::tmp_table_param:
tab->tmp_table_param= new TMP_TABLE_PARAM(tmp_table_param);
Then, call create_tmp_table:
TABLE* table= create_tmp_table(thd, tab->tmp_table_param, *table_fields,
table_group, distinct,
...
create_tmp_table fills certain members of TMP_TABLE_PARAM, e.g. recinfo .
That is, tab->tmp_table_param has data describing the temporary table.
Then, execution proceeds and eventually we reach JOIN::rollup_write_data
It has this call:
if (create_internal_tmp_table_from_heap(thd, table_arg,
tmp_table_param.start_recinfo,
&tmp_table_param.recinfo,
Note that it uses JOIN::tmp_table_param, while the data describing the
temptable is in join_tab->tmp_table_param.
Going one frame up into end_write_group, I see:
int error= table->file->ha_write_tmp_row(table->record[0]);
if (error &&
create_internal_tmp_table_from_heap(join->thd, table,
join_tab->tmp_table_param->start_recinfo,
&join_tab->tmp_table_param->recinfo,
error, 0, NULL))
DBUG_RETURN(NESTED_LOOP_ERROR);
}
if (join->rollup.state != ROLLUP::STATE_NONE)
{
if (join->rollup_write_data((uint) (idx+1), table))
DBUG_RETURN(NESTED_LOOP_ERROR);
}
So I guess it's better if rollup_write_data used join_tab->tmp_table_param, just like create_internal_tmp_table_from_heap call above does.
Bug
Major
In the function JOIN::create_postjoin_aggr_table in sql_select.cc, the tmp_table_param field is not updated by the new values of the tab->tmp_table_param.
TABLE* table= create_tmp_table(thd, tab->tmp_table_param, *table_fields,table_group, distinct,save_sum_fields, select_options, table_rows_limit,the tab->tmp_table_param is updated here, but these are not updated in join->tmp_table_param.