1
0
mirror of https://github.com/MariaDB/server.git synced 2025-08-08 11:22:35 +03:00

Backport of (see below) + temporary measures to make SJ-Materialization work with join buffering.

Date: Mon, 01 Nov 2010 15:15:25 -0000
3272 Roy Lyseng        2010-11-01
Bug#52068: Optimizer generates invalid semijoin materialization plan

When MaterializeScan semijoin strategy was used and there were one
or more outer dependent tables before the semijoin tables, the scan
over the materialized table was not properly reset for each row of
the prefix outer tables.

Example: suppose we have a join order:

  ot1 SJ-Mat-Scan(it2 it3)  ot4

Notice that this is called a MaterializeScan, even though there is an
outer table ahead of the materialized tables. Usually a MaterializeScan
has the outer tables after the materialized table, but this is
a special (but legal) case with outer dependent tables both before and
after the materialized table.

For each qualifying row from ot1, a new scan over the materialized
table must be set up. The code failed to do that, so all scans after
the first one returned zero rows from the materialized table.
This commit is contained in:
Sergey Petrunya
2011-01-13 19:25:31 +03:00
parent 959bf3c1ee
commit d2cbb10443
7 changed files with 185 additions and 0 deletions

View File

@@ -169,9 +169,17 @@ JOIN_TAB *JOIN_CACHE::get_next_table(JOIN_TAB *tab)
if (join_tab->first_sjm_sibling)
return tab;
uint i= tab-join->join_tab;
/*
Temporary measure before MWL#90 refactorings are there: if 'tab' is at upper
level (i.e. it's not inside an SJM nest), still include into the join buffer
the tables from within SJM nest. We might need the subquery's select list
columns, because SJ-Materialization-Scan upacks data to those.
while (sj_is_materialize_strategy(join->best_positions[i].sj_strategy) &&
i < join->tables)
i+= join->best_positions[i].n_sj_tables;
*/
return join->join_tab+i < join_tab ? join->join_tab+i : NULL;
}