Please sign in to comment.
This first patch prepared for the task MDEV-13369:
"Optimization for equi-joins of derived tables with GROUP BY" should be considered rather as a 'proof of concept'. The task itself is targeted at an optimization that employs re-writing equi-joins with grouping derived tables / views into lateral derived tables. Here's an example of such transformation: select t1.a,t.max,t.min from t1 [left] join (select a, max(t2.b) max, min(t2.b) min from t2 group by t2.a) as t on t1.a=t.a; => select t1.a,tl.max,tl.min from t1 [left] join lateral (select a, max(t2.b) max, min(t2.b) min from t2 where t1.a=t2.a) as t on 1=1; The transformation pushes the equi-join condition t1.a=t.a into the derived table making it dependent on table t1. It means that for every row from t1 a new derived table must be filled out. However the size of any of these derived tables is just a fraction of the original derived table t. One could say that transformation 'splits' the rows used for the GROUP BY operation into separate groups performing aggregation for a group only in the case when there is a match for the current row of t1. Apparently the transformation may produce a query with a better performance only in the case when - the GROUP BY list refers only to fields returned by the derived table - there is an index I on one of the tables T used in FROM list of the specification of the derived table whose prefix covers the the fields from the proper beginning of the GROUP BY list or fields that are equal to those fields. Whether the result of the re-writing can be executed faster depends on many factors: - the size of the original derived table - the size of the table T - whether the index I is clustering for table T - whether the index I fully covers the GROUP BY list. This patch only tries to improve the chosen execution plan using this transformation. It tries to do it only when the chosen plan reaches the derived table by a key whose prefix covers all the fields of the derived table produced by the fields of the table T from the GROUP BY list. The code of the patch does not evaluates the cost of the improved plan. If certain conditions are met the transformation is applied.
- Loading branch information...
Showing with 948 additions and 51 deletions.
- +438 −0 mysql-test/r/derived_cond_pushdown.result
- +2 −2 mysql-test/r/mysqld--help.result
- +97 −0 mysql-test/t/derived_cond_pushdown.test
- +10 −0 sql/item.h
- +25 −4 sql/sql_derived.cc
- +7 −2 sql/sql_lex.cc
- +1 −0 sql/sql_lex.h
- +4 −1 sql/sql_priv.h
- +345 −40 sql/sql_select.cc
- +16 −1 sql/sql_select.h
- +1 −1 sql/sql_union.cc
- +1 −0 sql/sys_vars.cc
- +1 −0 sql/table.h
Oops, something went wrong.