Browse Source
MDEV-25008: UPDATE/DELETE: Cost-based choice IN->EXISTS vs Materialization
MDEV-25008: UPDATE/DELETE: Cost-based choice IN->EXISTS vs Materialization
Single-table UPDATE/DELETE didn't provide outer_lookup_keys value for subqueries. This didn't allow to make a meaningful choice between IN->EXISTS and Materialization strategies for subqueries. Fix this: * Make UPDATE/DELETE save Sql_cmd_dml::scanned_rows, * Then, subquery's JOIN::choose_subquery_plan() can fetch it from there for outer_lookup_keys Details: UPDATE/DELETE now calls select_lex->optimize_unflattened_subqueries() twice, like SELECT does (first call optimize_constant_subquries() in JOIN::optimize_inner(), then call optimize_unflattened_subqueries() in JOIN::optimize_stage2()): 1. Call with const_only=true before any optimizations. This allows range optimizer and others to use the values of cheap const subqueries. 2. Call it with const_only=false after range optimizer, partition pruning, etc. outer_lookup_keys value is provided, so it's possible to pick a good subquery strategy. Note: PROTECT_STATEMENT_MEMROOT requires that first SP execution performs subquery optimization for all subqueries, even for degenerate query plans like "Impossible WHERE". Due to that, we ensure that the call to optimize_unflattened_subqueries (with const_only=false) even for degenerate query plans still happens, as was the case before this change.bb-11.7-mdev-25008
No known key found for this signature in database
GPG Key ID: 3DD1B35105743563
16 changed files with 334 additions and 26 deletions
-
33mysql-test/main/delete.result
-
37mysql-test/main/delete.test
-
21mysql-test/main/ps.result
-
26mysql-test/main/ps.test
-
34mysql-test/main/ps_mem_leaks.test
-
33mysql-test/main/update.result
-
36mysql-test/main/update.test
-
4sql/opt_range.cc
-
15sql/opt_subselect.cc
-
2sql/sql_base.cc
-
7sql/sql_cmd.h
-
50sql/sql_delete.cc
-
1sql/sql_lex.h
-
1sql/sql_select.cc
-
9sql/sql_select.h
-
51sql/sql_update.cc
Write
Preview
Loading…
Cancel
Save
Reference in new issue