mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-31 02:51:44 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/r/subselect_mat.result

2842 lines
138 KiB
Text
Raw Normal View History

Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @subselect_mat_test_optimizer_switch_value='materialization=on,in_to_exists=off,semijoin=off';
set @subselect_sj_mat_tmp= @@optimizer_switch;
Fixed LP bug #889750. If the optimizer switch 'semijoin_with_cache' is set to 'off' then join cache cannot be used to join inner tables of a semijoin. Also fixed a bug in the function check_join_cache_usage() that led to wrong output of the EXPLAIN commands for some test cases.
2011-11-15 13:03:00 -08:00
set optimizer_switch=ifnull(@subselect_mat_test_optimizer_switch_value, 'semijoin=on,firstmatch=on,loosescan=on,semijoin_with_cache=on');
Set the default to be mrr=off,mrr_sort_keys=off: - Set the default - Adjust the testcases so that 'new' tests are run with optimizations turned on. - Pull out relevant tests from "irrelevant" tests and run them with optimizations on. - Run range.test and innodb.test with both mrr=on and mrr=off
2011-07-08 18:46:47 +04:00
set optimizer_switch='mrr=on,mrr_sort_keys=on,index_condition_pushdown=on';
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @optimizer_switch_local_default= @@optimizer_switch;
Made join_cache_level == 2 by default.
2011-12-15 14:26:59 -08:00
set @save_join_cache_level=@@join_cache_level;
set join_cache_level=1;
BUG#836532: Crash in Item_equal_fields_iterator::get_curr_field with semijoin+materialization - Item_in_subselect::inject_in_to_exists_cond() should not call ((Item_cond*)join->conds)->argument_list()->concat(join->cond_equal->current_level) as that makes two lists share their tail, and the cond_equal list will end up containing non-Item_equal objects when substitute_for_best_equal_field() walks through join->conds and replaces all Item_equal objects with Item_func_eq objects. - So, instead of using List::concat(), manually copy entries from one list to another.
2011-09-04 16:35:37 +04:00
drop table if exists t1, t2, t3, t4, t5, t1i, t2i, t3i;
- Update test results (trivial) - Code cleanup: remove garbage comments
2011-05-29 01:47:24 +04:00
drop table if exists columns;
drop table if exists t1_16, t2_16, t3_16;
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
drop view if exists v1, v2, v1m, v2m;
create table t1 (a1 char(8), a2 char(8));
create table t2 (b1 char(8), b2 char(8));
create table t3 (c1 char(8), c2 char(8));
insert into t1 values ('1 - 00', '2 - 00');
insert into t1 values ('1 - 01', '2 - 01');
insert into t1 values ('1 - 02', '2 - 02');
insert into t2 values ('1 - 01', '2 - 01');
insert into t2 values ('1 - 01', '2 - 01');
insert into t2 values ('1 - 02', '2 - 02');
insert into t2 values ('1 - 02', '2 - 02');
insert into t2 values ('1 - 03', '2 - 03');
insert into t3 values ('1 - 01', '2 - 01');
insert into t3 values ('1 - 02', '2 - 02');
insert into t3 values ('1 - 03', '2 - 03');
insert into t3 values ('1 - 04', '2 - 04');
create table t1i (a1 char(8), a2 char(8));
create table t2i (b1 char(8), b2 char(8));
create table t3i (c1 char(8), c2 char(8));
create index it1i1 on t1i (a1);
create index it1i2 on t1i (a2);
create index it1i3 on t1i (a1, a2);
create index it2i1 on t2i (b1);
create index it2i2 on t2i (b2);
create index it2i3 on t2i (b1, b2);
create index it3i1 on t3i (c1);
create index it3i2 on t3i (c2);
create index it3i3 on t3i (c1, c2);
insert into t1i select * from t1;
insert into t2i select * from t2;
insert into t3i select * from t3;
Post-merge fix for tests - bad .result merge - make .test file do not switch off both materialization and IN->EXISTS as that leads to error now.
2011-05-29 00:51:26 +04:00
set @@optimizer_switch='materialization=on,in_to_exists=off,firstmatch=off';
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
/******************************************************************************
* Simple tests.
******************************************************************************/
# non-indexed nullable fields
explain extended
select * from t1 where a1 in (select b1 from t2 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 5 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where <expr_cache><`test`.`t1`.`a1`>(<in_optimizer>(`test`.`t1`.`a1`,`test`.`t1`.`a1` in ( <materialize> (select `test`.`t2`.`b1` from `test`.`t2` where (`test`.`t2`.`b1` > '0') ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery2>`.`b1`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1 where a1 in (select b1 from t2 where b1 > '0');
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
select * from t1 where a1 in (select b1 from t2 where b1 > '0' group by b1);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 5 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where <expr_cache><`test`.`t1`.`a1`>(<in_optimizer>(`test`.`t1`.`a1`,`test`.`t1`.`a1` in ( <materialize> (select `test`.`t2`.`b1` from `test`.`t2` where (`test`.`t2`.`b1` > '0') ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery2>`.`b1`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1 where a1 in (select b1 from t2 where b1 > '0' group by b1);
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
select * from t1 where (a1, a2) in (select b1, b2 from t2 where b1 > '0' group by b1, b2);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 5 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t2`.`b1`,`test`.`t2`.`b2` from `test`.`t2` where (`test`.`t2`.`b1` > '0') ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1`.`a2` = `<subquery2>`.`b2`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1 where (a1, a2) in (select b1, b2 from t2 where b1 > '0' group by b1, b2);
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
select * from t1 where (a1, a2) in (select b1, min(b2) from t2 where b1 > '0' group by b1);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 5 100.00 Using where; Using temporary
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t2`.`b1`,min(`test`.`t2`.`b2`) from `test`.`t2` where (`test`.`t2`.`b1` > '0') group by `test`.`t2`.`b1` ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1`.`a2` = `<subquery2>`.`min(b2)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1 where (a1, a2) in (select b1, min(b2) from t2 where b1 > '0' group by b1);
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
select * from t1i where a1 in (select b1 from t2i where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
Fix test results and testuite valgrind failures
2010-06-11 16:57:41 +04:00
1 PRIMARY t1i index NULL _it1_idx # NULL 3 100.00 Using where;
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2i index it2i1,it2i3 it2i1 # NULL 5 100.00 Using where;
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1i`.`a1` AS `a1`,`test`.`t1i`.`a2` AS `a2` from `test`.`t1i` where <expr_cache><`test`.`t1i`.`a1`>(<in_optimizer>(`test`.`t1i`.`a1`,`test`.`t1i`.`a1` in ( <materialize> (select `test`.`t2i`.`b1` from `test`.`t2i` where (`test`.`t2i`.`b1` > '0') ), <primary_index_lookup>(`test`.`t1i`.`a1` in <temporary table> on distinct_key where ((`test`.`t1i`.`a1` = `<subquery2>`.`b1`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1i where a1 in (select b1 from t2i where b1 > '0');
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
select * from t1i where a1 in (select max(b1) from t2i where b1 > '0' group by b1);
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
id select_type table type possible_keys key key_len ref rows filtered Extra
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - Code cleanu. - Make MWL#90 code require @@optimizer_switch='semijoin=on' - Update test results with the above - Fork subselect_mat.test - we want to check both semi-join materialization, which now has broader scope and non-semijoin materialization.
2010-05-25 10:32:15 +04:00
1 PRIMARY t1i index NULL # 18 # 3 100.00 #
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
2 MATERIALIZED t2i index it2i1,it2i3 # 9 # 5 100.00 #
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
Note 1003 select `test`.`t1i`.`a1` AS `a1`,`test`.`t1i`.`a2` AS `a2` from `test`.`t1i` where <expr_cache><`test`.`t1i`.`a1`>(<in_optimizer>(`test`.`t1i`.`a1`,`test`.`t1i`.`a1` in ( <materialize> (select max(`test`.`t2i`.`b1`) from `test`.`t2i` where (`test`.`t2i`.`b1` > '0') group by `test`.`t2i`.`b1` ), <primary_index_lookup>(`test`.`t1i`.`a1` in <temporary table> on distinct_key where ((`test`.`t1i`.`a1` = `<subquery2>`.`max(b1)`))))))
select * from t1i where a1 in (select max(b1) from t2i where b1 > '0' group by b1);
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
select * from t1i where (a1, a2) in (select b1, b2 from t2i where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
Fix test results and testuite valgrind failures
2010-06-11 16:57:41 +04:00
1 PRIMARY t1i index NULL _it1_idx # NULL 3 100.00 Using where;
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2i index it2i1,it2i3 it2i3 # NULL 5 100.00 Using where;
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1i`.`a1` AS `a1`,`test`.`t1i`.`a2` AS `a2` from `test`.`t1i` where <expr_cache><`test`.`t1i`.`a1`,`test`.`t1i`.`a2`>(<in_optimizer>((`test`.`t1i`.`a1`,`test`.`t1i`.`a2`),(`test`.`t1i`.`a1`,`test`.`t1i`.`a2`) in ( <materialize> (select `test`.`t2i`.`b1`,`test`.`t2i`.`b2` from `test`.`t2i` where (`test`.`t2i`.`b1` > '0') ), <primary_index_lookup>(`test`.`t1i`.`a1` in <temporary table> on distinct_key where ((`test`.`t1i`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1i`.`a2` = `<subquery2>`.`b2`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1i where (a1, a2) in (select b1, b2 from t2i where b1 > '0');
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
select * from t1i where (a1, a2) in (select b1, max(b2) from t2i where b1 > '0' group by b1);
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
id select_type table type possible_keys key key_len ref rows filtered Extra
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - Code cleanu. - Make MWL#90 code require @@optimizer_switch='semijoin=on' - Update test results with the above - Fork subselect_mat.test - we want to check both semi-join materialization, which now has broader scope and non-semijoin materialization.
2010-05-25 10:32:15 +04:00
1 PRIMARY t1i index NULL # # # 3 100.00 #
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2i range it2i1,it2i3 # # # 3 100.00 #
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
Note 1003 select `test`.`t1i`.`a1` AS `a1`,`test`.`t1i`.`a2` AS `a2` from `test`.`t1i` where <expr_cache><`test`.`t1i`.`a1`,`test`.`t1i`.`a2`>(<in_optimizer>((`test`.`t1i`.`a1`,`test`.`t1i`.`a2`),(`test`.`t1i`.`a1`,`test`.`t1i`.`a2`) in ( <materialize> (select `test`.`t2i`.`b1`,max(`test`.`t2i`.`b2`) from `test`.`t2i` where (`test`.`t2i`.`b1` > '0') group by `test`.`t2i`.`b1` ), <primary_index_lookup>(`test`.`t1i`.`a1` in <temporary table> on distinct_key where ((`test`.`t1i`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1i`.`a2` = `<subquery2>`.`max(b2)`))))))
select * from t1i where (a1, a2) in (select b1, max(b2) from t2i where b1 > '0' group by b1);
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
select * from t1i where (a1, a2) in (select b1, min(b2) from t2i where b1 > '0' group by b1);
id select_type table type possible_keys key key_len ref rows filtered Extra
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - Code cleanu. - Make MWL#90 code require @@optimizer_switch='semijoin=on' - Update test results with the above - Fork subselect_mat.test - we want to check both semi-join materialization, which now has broader scope and non-semijoin materialization.
2010-05-25 10:32:15 +04:00
1 PRIMARY t1i index NULL # # # 3 100.00 #
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2i range it2i1,it2i3 # # # 3 100.00 #
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1i`.`a1` AS `a1`,`test`.`t1i`.`a2` AS `a2` from `test`.`t1i` where <expr_cache><`test`.`t1i`.`a1`,`test`.`t1i`.`a2`>(<in_optimizer>((`test`.`t1i`.`a1`,`test`.`t1i`.`a2`),(`test`.`t1i`.`a1`,`test`.`t1i`.`a2`) in ( <materialize> (select `test`.`t2i`.`b1`,min(`test`.`t2i`.`b2`) from `test`.`t2i` where (`test`.`t2i`.`b1` > '0') group by `test`.`t2i`.`b1` ), <primary_index_lookup>(`test`.`t1i`.`a1` in <temporary table> on distinct_key where ((`test`.`t1i`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1i`.`a2` = `<subquery2>`.`min(b2)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1i where (a1, a2) in (select b1, min(b2) from t2i where b1 > '0' group by b1);
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
select * from t1 where (a1, a2) in (select b1, max(b2) from t2i group by b1);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2i range NULL it2i3 9 NULL 3 100.00 Using index for group-by
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t2i`.`b1`,max(`test`.`t2i`.`b2`) from `test`.`t2i` group by `test`.`t2i`.`b1` ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1`.`a2` = `<subquery2>`.`max(b2)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1 where (a1, a2) in (select b1, max(b2) from t2i group by b1);
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
prepare st1 from "explain select * from t1 where (a1, a2) in (select b1, max(b2) from t2i group by b1)";
execute st1;
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2i range NULL it2i3 9 NULL 3 Using index for group-by
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
execute st1;
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2i range NULL it2i3 9 NULL 3 Using index for group-by
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
prepare st2 from "select * from t1 where (a1, a2) in (select b1, max(b2) from t2i group by b1)";
execute st2;
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
execute st2;
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
select * from t1 where (a1, a2) in (select b1, min(b2) from t2i where b1 > '0' group by b1);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2i range it2i1,it2i3 it2i3 18 NULL 3 100.00 Using where; Using index for group-by
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t2i`.`b1`,min(`test`.`t2i`.`b2`) from `test`.`t2i` where (`test`.`t2i`.`b1` > '0') group by `test`.`t2i`.`b1` ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1`.`a2` = `<subquery2>`.`min(b2)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1 where (a1, a2) in (select b1, min(b2) from t2i where b1 > '0' group by b1);
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
select * from t1 where (a1, a2) in (select b1, min(b2) from t2i limit 1,1);
after merge changes: * rename all debugging related command-line options and variables to start from "debug-", and made them all OFF by default. * replace "MySQL" with "MariaDB" in error messages * "Cast ... converted ... integer to it's ... complement" is now a note, not a warning * @@query_cache_strip_comments now has a session scope, not global.
2011-12-12 23:58:40 +01:00
ERROR 42000: This version of MariaDB doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery'
Post-merge fix for tests - bad .result merge - make .test file do not switch off both materialization and IN->EXISTS as that leads to error now.
2011-05-29 00:51:26 +04:00
set @save_optimizer_switch=@@optimizer_switch;
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @@optimizer_switch=@optimizer_switch_local_default;
set @@optimizer_switch='semijoin=off';
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
prepare st1 from
"select * from t1 where (a1, a2) in (select b1, min(b2) from t2 where b1 > '0' group by b1)";
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @@optimizer_switch=@optimizer_switch_local_default;
set @@optimizer_switch='materialization=off,in_to_exists=on';
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
execute st1;
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @@optimizer_switch=@optimizer_switch_local_default;
set @@optimizer_switch='semijoin=off';
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
execute st1;
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @@optimizer_switch=@optimizer_switch_local_default;
set @@optimizer_switch='materialization=off,in_to_exists=on';
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
prepare st1 from
"select * from t1 where (a1, a2) in (select b1, min(b2) from t2 where b1 > '0' group by b1)";
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @@optimizer_switch=@optimizer_switch_local_default;
set @@optimizer_switch='semijoin=off';
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
execute st1;
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @@optimizer_switch=@optimizer_switch_local_default;
set @@optimizer_switch='materialization=off,in_to_exists=on';
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
execute st1;
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
Post-merge fix for tests - bad .result merge - make .test file do not switch off both materialization and IN->EXISTS as that leads to error now.
2011-05-29 00:51:26 +04:00
set @@optimizer_switch=@save_optimizer_switch;
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
explain extended
select * from t1 where (a1, a2) in (select b1, b2 from t2 order by b1, b2);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 5 100.00
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t2`.`b1`,`test`.`t2`.`b2` from `test`.`t2` order by `test`.`t2`.`b1`,`test`.`t2`.`b2` ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1`.`a2` = `<subquery2>`.`b2`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1 where (a1, a2) in (select b1, b2 from t2 order by b1, b2);
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
select * from t1i where (a1, a2) in (select b1, b2 from t2i order by b1, b2);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1i index NULL it1i3 18 NULL 3 100.00 Using where; Using index
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2i index NULL it2i3 18 NULL 5 100.00 Using index
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1i`.`a1` AS `a1`,`test`.`t1i`.`a2` AS `a2` from `test`.`t1i` where <expr_cache><`test`.`t1i`.`a1`,`test`.`t1i`.`a2`>(<in_optimizer>((`test`.`t1i`.`a1`,`test`.`t1i`.`a2`),(`test`.`t1i`.`a1`,`test`.`t1i`.`a2`) in ( <materialize> (select `test`.`t2i`.`b1`,`test`.`t2i`.`b2` from `test`.`t2i` order by `test`.`t2i`.`b1`,`test`.`t2i`.`b2` ), <primary_index_lookup>(`test`.`t1i`.`a1` in <temporary table> on distinct_key where ((`test`.`t1i`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1i`.`a2` = `<subquery2>`.`b2`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1i where (a1, a2) in (select b1, b2 from t2i order by b1, b2);
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
/******************************************************************************
* Views, UNIONs, several levels of nesting.
******************************************************************************/
# materialize the result of subquery over temp-table view
create algorithm=merge view v1 as
select b1, c2 from t2, t3 where b2 > c2;
create algorithm=merge view v2 as
select b1, c2 from t2, t3 group by b2, c2;
Warnings:
Warning 1354 View merge algorithm can't be used here for now (assumed undefined algorithm)
create algorithm=temptable view v1m as
select b1, c2 from t2, t3 where b2 > c2;
create algorithm=temptable view v2m as
select b1, c2 from t2, t3 group by b2, c2;
select * from v1 where (c2, b1) in (select c2, b1 from v2 where b1 is not null);
b1 c2
1 - 02 2 - 01
1 - 02 2 - 01
1 - 03 2 - 01
1 - 03 2 - 02
select * from v1 where (c2, b1) in (select distinct c2, b1 from v2 where b1 is not null);
b1 c2
1 - 02 2 - 01
1 - 02 2 - 01
1 - 03 2 - 01
1 - 03 2 - 02
select * from v1m where (c2, b1) in (select c2, b1 from v2m where b1 is not null);
b1 c2
1 - 02 2 - 01
1 - 02 2 - 01
1 - 03 2 - 01
1 - 03 2 - 02
select * from v1m where (c2, b1) in (select distinct c2, b1 from v2m where b1 is not null);
b1 c2
1 - 02 2 - 01
1 - 02 2 - 01
1 - 03 2 - 01
1 - 03 2 - 02
drop view v1, v2, v1m, v2m;
explain extended
select * from t1
where (a1, a2) in (select b1, b2 from t2 where b1 > '0') and
(a1, a2) in (select c1, c2 from t3
where (c1, c2) in (select b1, b2 from t2i where b2 > '0'));
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
3 MATERIALIZED t3 ALL NULL NULL NULL NULL 4 100.00 Using where
4 MATERIALIZED t2i index it2i2 it2i3 18 NULL 5 100.00 Using where; Using index
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 5 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where (<expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t2`.`b1`,`test`.`t2`.`b2` from `test`.`t2` where (`test`.`t2`.`b1` > '0') ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1`.`a2` = `<subquery2>`.`b2`)))))) and <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t3`.`c1`,`test`.`t3`.`c2` from `test`.`t3` where <expr_cache><`test`.`t3`.`c1`,`test`.`t3`.`c2`>(<in_optimizer>((`test`.`t3`.`c1`,`test`.`t3`.`c2`),(`test`.`t3`.`c1`,`test`.`t3`.`c2`) in ( <materialize> (select `test`.`t2i`.`b1`,`test`.`t2i`.`b2` from `test`.`t2i` where (`test`.`t2i`.`b2` > '0') ), <primary_index_lookup>(`test`.`t3`.`c1` in <temporary table> on distinct_key where ((`test`.`t3`.`c1` = `<subquery4>`.`b1`) and (`test`.`t3`.`c2` = `<subquery4>`.`b2`)))))) ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery3>`.`c1`) and (`test`.`t1`.`a2` = `<subquery3>`.`c2`)))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1
where (a1, a2) in (select b1, b2 from t2 where b1 > '0') and
(a1, a2) in (select c1, c2 from t3
where (c1, c2) in (select b1, b2 from t2i where b2 > '0'));
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
select * from t1i
where (a1, a2) in (select b1, b2 from t2i where b1 > '0') and
(a1, a2) in (select c1, c2 from t3i
where (c1, c2) in (select b1, b2 from t2i where b2 > '0'));
id select_type table type possible_keys key key_len ref rows filtered Extra
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - Code cleanu. - Make MWL#90 code require @@optimizer_switch='semijoin=on' - Update test results with the above - Fork subselect_mat.test - we want to check both semi-join materialization, which now has broader scope and non-semijoin materialization.
2010-05-25 10:32:15 +04:00
1 PRIMARY t1i index NULL # # # 3 100.00 #
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
3 MATERIALIZED t3i index NULL # # # 4 100.00 #
4 MATERIALIZED t2i index it2i2 # # # 5 100.00 #
2 MATERIALIZED t2i index it2i1,it2i3 # # # 5 100.00 #
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1i`.`a1` AS `a1`,`test`.`t1i`.`a2` AS `a2` from `test`.`t1i` where (<expr_cache><`test`.`t1i`.`a1`,`test`.`t1i`.`a2`>(<in_optimizer>((`test`.`t1i`.`a1`,`test`.`t1i`.`a2`),(`test`.`t1i`.`a1`,`test`.`t1i`.`a2`) in ( <materialize> (select `test`.`t2i`.`b1`,`test`.`t2i`.`b2` from `test`.`t2i` where (`test`.`t2i`.`b1` > '0') ), <primary_index_lookup>(`test`.`t1i`.`a1` in <temporary table> on distinct_key where ((`test`.`t1i`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1i`.`a2` = `<subquery2>`.`b2`)))))) and <expr_cache><`test`.`t1i`.`a1`,`test`.`t1i`.`a2`>(<in_optimizer>((`test`.`t1i`.`a1`,`test`.`t1i`.`a2`),(`test`.`t1i`.`a1`,`test`.`t1i`.`a2`) in ( <materialize> (select `test`.`t3i`.`c1`,`test`.`t3i`.`c2` from `test`.`t3i` where <expr_cache><`test`.`t3i`.`c1`,`test`.`t3i`.`c2`>(<in_optimizer>((`test`.`t3i`.`c1`,`test`.`t3i`.`c2`),(`test`.`t3i`.`c1`,`test`.`t3i`.`c2`) in ( <materialize> (select `test`.`t2i`.`b1`,`test`.`t2i`.`b2` from `test`.`t2i` where (`test`.`t2i`.`b2` > '0') ), <primary_index_lookup>(`test`.`t3i`.`c1` in <temporary table> on distinct_key where ((`test`.`t3i`.`c1` = `<subquery4>`.`b1`) and (`test`.`t3i`.`c2` = `<subquery4>`.`b2`)))))) ), <primary_index_lookup>(`test`.`t1i`.`a1` in <temporary table> on distinct_key where ((`test`.`t1i`.`a1` = `<subquery3>`.`c1`) and (`test`.`t1i`.`a2` = `<subquery3>`.`c2`)))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1i
where (a1, a2) in (select b1, b2 from t2i where b1 > '0') and
(a1, a2) in (select c1, c2 from t3i
where (c1, c2) in (select b1, b2 from t2i where b2 > '0'));
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
select * from t1
where (a1, a2) in (select b1, b2 from t2
where b2 in (select c2 from t3 where c2 LIKE '%02') or
b2 in (select c2 from t3 where c2 LIKE '%03')) and
(a1, a2) in (select c1, c2 from t3
where (c1, c2) in (select b1, b2 from t2i where b2 > '0'));
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
5 MATERIALIZED t3 ALL NULL NULL NULL NULL 4 100.00 Using where
6 MATERIALIZED t2i index it2i2 it2i3 18 NULL 5 100.00 Using where; Using index
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 5 100.00 Using where
4 MATERIALIZED t3 ALL NULL NULL NULL NULL 4 100.00 Using where
3 MATERIALIZED t3 ALL NULL NULL NULL NULL 4 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where (<expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t2`.`b1`,`test`.`t2`.`b2` from `test`.`t2` where (<expr_cache><`test`.`t2`.`b2`>(<in_optimizer>(`test`.`t2`.`b2`,`test`.`t2`.`b2` in ( <materialize> (select `test`.`t3`.`c2` from `test`.`t3` where (`test`.`t3`.`c2` like '%02') ), <primary_index_lookup>(`test`.`t2`.`b2` in <temporary table> on distinct_key where ((`test`.`t2`.`b2` = `<subquery3>`.`c2`)))))) or <expr_cache><`test`.`t2`.`b2`>(<in_optimizer>(`test`.`t2`.`b2`,`test`.`t2`.`b2` in ( <materialize> (select `test`.`t3`.`c2` from `test`.`t3` where (`test`.`t3`.`c2` like '%03') ), <primary_index_lookup>(`test`.`t2`.`b2` in <temporary table> on distinct_key where ((`test`.`t2`.`b2` = `<subquery4>`.`c2`))))))) ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1`.`a2` = `<subquery2>`.`b2`)))))) and <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t3`.`c1`,`test`.`t3`.`c2` from `test`.`t3` where <expr_cache><`test`.`t3`.`c1`,`test`.`t3`.`c2`>(<in_optimizer>((`test`.`t3`.`c1`,`test`.`t3`.`c2`),(`test`.`t3`.`c1`,`test`.`t3`.`c2`) in ( <materialize> (select `test`.`t2i`.`b1`,`test`.`t2i`.`b2` from `test`.`t2i` where (`test`.`t2i`.`b2` > '0') ), <primary_index_lookup>(`test`.`t3`.`c1` in <temporary table> on distinct_key where ((`test`.`t3`.`c1` = `<subquery6>`.`b1`) and (`test`.`t3`.`c2` = `<subquery6>`.`b2`)))))) ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery5>`.`c1`) and (`test`.`t1`.`a2` = `<subquery5>`.`c2`)))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1
where (a1, a2) in (select b1, b2 from t2
where b2 in (select c2 from t3 where c2 LIKE '%02') or
b2 in (select c2 from t3 where c2 LIKE '%03')) and
(a1, a2) in (select c1, c2 from t3
where (c1, c2) in (select b1, b2 from t2i where b2 > '0'));
a1 a2
1 - 02 2 - 02
explain extended
select * from t1
where (a1, a2) in (select b1, b2 from t2
where b2 in (select c2 from t3 t3a where c1 = a1) or
b2 in (select c2 from t3 t3b where c2 LIKE '%03')) and
(a1, a2) in (select c1, c2 from t3 t3c
where (c1, c2) in (select b1, b2 from t2i where b2 > '0'));
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
5 MATERIALIZED t3c ALL NULL NULL NULL NULL 4 100.00 Using where
6 MATERIALIZED t2i index it2i2 it2i3 18 NULL 5 100.00 Using where; Using index
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
2 DEPENDENT SUBQUERY t2 ALL NULL NULL NULL NULL 5 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
4 MATERIALIZED t3b ALL NULL NULL NULL NULL 4 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
3 DEPENDENT SUBQUERY t3a ALL NULL NULL NULL NULL 4 100.00 Using where
Warnings:
Note 1276 Field or reference 'test.t1.a1' of SELECT #3 was resolved in SELECT #1
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where (<expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),<exists>(select `test`.`t2`.`b1`,`test`.`t2`.`b2` from `test`.`t2` where ((<expr_cache><`test`.`t2`.`b2`,`test`.`t1`.`a1`>(<in_optimizer>(`test`.`t2`.`b2`,<exists>(select `test`.`t3a`.`c2` from `test`.`t3` `t3a` where ((`test`.`t3a`.`c1` = `test`.`t1`.`a1`) and (<cache>(`test`.`t2`.`b2`) = `test`.`t3a`.`c2`))))) or <expr_cache><`test`.`t2`.`b2`>(<in_optimizer>(`test`.`t2`.`b2`,`test`.`t2`.`b2` in ( <materialize> (select `test`.`t3b`.`c2` from `test`.`t3` `t3b` where (`test`.`t3b`.`c2` like '%03') ), <primary_index_lookup>(`test`.`t2`.`b2` in <temporary table> on distinct_key where ((`test`.`t2`.`b2` = `<subquery4>`.`c2`))))))) and (<cache>(`test`.`t1`.`a1`) = `test`.`t2`.`b1`) and (<cache>(`test`.`t1`.`a2`) = `test`.`t2`.`b2`))))) and <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t3c`.`c1`,`test`.`t3c`.`c2` from `test`.`t3` `t3c` where <expr_cache><`test`.`t3c`.`c1`,`test`.`t3c`.`c2`>(<in_optimizer>((`test`.`t3c`.`c1`,`test`.`t3c`.`c2`),(`test`.`t3c`.`c1`,`test`.`t3c`.`c2`) in ( <materialize> (select `test`.`t2i`.`b1`,`test`.`t2i`.`b2` from `test`.`t2i` where (`test`.`t2i`.`b2` > '0') ), <primary_index_lookup>(`test`.`t3c`.`c1` in <temporary table> on distinct_key where ((`test`.`t3c`.`c1` = `<subquery6>`.`b1`) and (`test`.`t3c`.`c2` = `<subquery6>`.`b2`)))))) ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery5>`.`c1`) and (`test`.`t1`.`a2` = `<subquery5>`.`c2`)))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1
where (a1, a2) in (select b1, b2 from t2
where b2 in (select c2 from t3 t3a where c1 = a1) or
b2 in (select c2 from t3 t3b where c2 LIKE '%03')) and
(a1, a2) in (select c1, c2 from t3 t3c
where (c1, c2) in (select b1, b2 from t2i where b2 > '0'));
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
(select * from t1
where (a1, a2) in (select b1, b2 from t2
where b2 in (select c2 from t3 where c2 LIKE '%02') or
b2 in (select c2 from t3 where c2 LIKE '%03')
group by b1, b2) and
(a1, a2) in (select c1, c2 from t3
where (c1, c2) in (select b1, b2 from t2i where b2 > '0')))
UNION
(select * from t1i
where (a1, a2) in (select b1, b2 from t2i where b1 > '0') and
(a1, a2) in (select c1, c2 from t3i
where (c1, c2) in (select b1, b2 from t2i where b2 > '0')));
id select_type table type possible_keys key key_len ref rows filtered Extra
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - Make test results handle same-cost QEP races
2010-04-06 14:35:33 +04:00
1 PRIMARY t1 ALL NULL # # # 3 100.00 #
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
5 MATERIALIZED t3 ALL NULL # # # 4 100.00 #
6 MATERIALIZED t2i index it2i2 # # # 5 100.00 #
2 MATERIALIZED t2 ALL NULL # # # 5 100.00 #
4 MATERIALIZED t3 ALL NULL # # # 4 100.00 #
3 MATERIALIZED t3 ALL NULL # # # 4 100.00 #
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - Code cleanu. - Make MWL#90 code require @@optimizer_switch='semijoin=on' - Update test results with the above - Fork subselect_mat.test - we want to check both semi-join materialization, which now has broader scope and non-semijoin materialization.
2010-05-25 10:32:15 +04:00
7 UNION t1i index NULL # # # 3 100.00 #
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
9 MATERIALIZED t3i index NULL # # # 4 100.00 #
10 MATERIALIZED t2i index it2i2 # # # 5 100.00 #
8 MATERIALIZED t2i index it2i1,it2i3 # # # 5 100.00 #
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - Make test results handle same-cost QEP races
2010-04-06 14:35:33 +04:00
NULL UNION RESULT <union1,7> ALL NULL # # # NULL NULL #
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
Note 1003 (select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where (<expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t2`.`b1`,`test`.`t2`.`b2` from `test`.`t2` where (<expr_cache><`test`.`t2`.`b2`>(<in_optimizer>(`test`.`t2`.`b2`,`test`.`t2`.`b2` in ( <materialize> (select `test`.`t3`.`c2` from `test`.`t3` where (`test`.`t3`.`c2` like '%02') ), <primary_index_lookup>(`test`.`t2`.`b2` in <temporary table> on distinct_key where ((`test`.`t2`.`b2` = `<subquery3>`.`c2`)))))) or <expr_cache><`test`.`t2`.`b2`>(<in_optimizer>(`test`.`t2`.`b2`,`test`.`t2`.`b2` in ( <materialize> (select `test`.`t3`.`c2` from `test`.`t3` where (`test`.`t3`.`c2` like '%03') ), <primary_index_lookup>(`test`.`t2`.`b2` in <temporary table> on distinct_key where ((`test`.`t2`.`b2` = `<subquery4>`.`c2`))))))) ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1`.`a2` = `<subquery2>`.`b2`)))))) and <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t3`.`c1`,`test`.`t3`.`c2` from `test`.`t3` where <expr_cache><`test`.`t3`.`c1`,`test`.`t3`.`c2`>(<in_optimizer>((`test`.`t3`.`c1`,`test`.`t3`.`c2`),(`test`.`t3`.`c1`,`test`.`t3`.`c2`) in ( <materialize> (select `test`.`t2i`.`b1`,`test`.`t2i`.`b2` from `test`.`t2i` where (`test`.`t2i`.`b2` > '0') ), <primary_index_lookup>(`test`.`t3`.`c1` in <temporary table> on distinct_key where ((`test`.`t3`.`c1` = `<subquery6>`.`b1`) and (`test`.`t3`.`c2` = `<subquery6>`.`b2`)))))) ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery5>`.`c1`) and (`test`.`t1`.`a2` = `<subquery5>`.`c2`)))))))) union (select `test`.`t1i`.`a1` AS `a1`,`test`.`t1i`.`a2` AS `a2` from `test`.`t1i` where (<expr_cache><`test`.`t1i`.`a1`,`test`.`t1i`.`a2`>(<in_optimizer>((`test`.`t1i`.`a1`,`test`.`t1i`.`a2`),(`test`.`t1i`.`a1`,`test`.`t1i`.`a2`) in ( <materialize> (select `test`.`t2i`.`b1`,`test`.`t2i`.`b2` from `test`.`t2i` where (`test`.`t2i`.`b1` > '0') ), <primary_index_lookup>(`test`.`t1i`.`a1` in <temporary table> on distinct_key where ((`test`.`t1i`.`a1` = `<subquery8>`.`b1`) and (`test`.`t1i`.`a2` = `<subquery8>`.`b2`)))))) and <expr_cache><`test`.`t1i`.`a1`,`test`.`t1i`.`a2`>(<in_optimizer>((`test`.`t1i`.`a1`,`test`.`t1i`.`a2`),(`test`.`t1i`.`a1`,`test`.`t1i`.`a2`) in ( <materialize> (select `test`.`t3i`.`c1`,`test`.`t3i`.`c2` from `test`.`t3i` where <expr_cache><`test`.`t3i`.`c1`,`test`.`t3i`.`c2`>(<in_optimizer>((`test`.`t3i`.`c1`,`test`.`t3i`.`c2`),(`test`.`t3i`.`c1`,`test`.`t3i`.`c2`) in ( <materialize> (select `test`.`t2i`.`b1`,`test`.`t2i`.`b2` from `test`.`t2i` where (`test`.`t2i`.`b2` > '0') ), <primary_index_lookup>(`test`.`t3i`.`c1` in <temporary table> on distinct_key where ((`test`.`t3i`.`c1` = `<subquery10>`.`b1`) and (`test`.`t3i`.`c2` = `<subquery10>`.`b2`)))))) ), <primary_index_lookup>(`test`.`t1i`.`a1` in <temporary table> on distinct_key where ((`test`.`t1i`.`a1` = `<subquery9>`.`c1`) and (`test`.`t1i`.`a2` = `<subquery9>`.`c2`))))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
(select * from t1
where (a1, a2) in (select b1, b2 from t2
where b2 in (select c2 from t3 where c2 LIKE '%02') or
b2 in (select c2 from t3 where c2 LIKE '%03')
group by b1, b2) and
(a1, a2) in (select c1, c2 from t3
where (c1, c2) in (select b1, b2 from t2i where b2 > '0')))
UNION
(select * from t1i
where (a1, a2) in (select b1, b2 from t2i where b1 > '0') and
(a1, a2) in (select c1, c2 from t3i
where (c1, c2) in (select b1, b2 from t2i where b2 > '0')));
a1 a2
1 - 02 2 - 02
1 - 01 2 - 01
explain extended
select * from t1
where (a1, a2) in (select * from t1 where a1 > '0' UNION select * from t2 where b1 < '9') and
(a1, a2) in (select c1, c2 from t3
where (c1, c2) in (select b1, b2 from t2i where b2 > '0'));
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
4 MATERIALIZED t3 ALL NULL NULL NULL NULL 4 100.00 Using where
5 MATERIALIZED t2i index it2i2 it2i3 18 NULL 5 100.00 Using where; Using index
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
2 DEPENDENT SUBQUERY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
3 DEPENDENT UNION t2 ALL NULL NULL NULL NULL 5 100.00 Using where
NULL UNION RESULT <union2,3> ALL NULL NULL NULL NULL NULL NULL
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where (<expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),<exists>(select `test`.`t1`.`a1`,`test`.`t1`.`a2` from `test`.`t1` where ((`test`.`t1`.`a1` > '0') and (<cache>(`test`.`t1`.`a1`) = `test`.`t1`.`a1`) and (<cache>(`test`.`t1`.`a2`) = `test`.`t1`.`a2`)) union select `test`.`t2`.`b1`,`test`.`t2`.`b2` from `test`.`t2` where ((`test`.`t2`.`b1` < '9') and (<cache>(`test`.`t1`.`a1`) = `test`.`t2`.`b1`) and (<cache>(`test`.`t1`.`a2`) = `test`.`t2`.`b2`))))) and <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),(`test`.`t1`.`a1`,`test`.`t1`.`a2`) in ( <materialize> (select `test`.`t3`.`c1`,`test`.`t3`.`c2` from `test`.`t3` where <expr_cache><`test`.`t3`.`c1`,`test`.`t3`.`c2`>(<in_optimizer>((`test`.`t3`.`c1`,`test`.`t3`.`c2`),(`test`.`t3`.`c1`,`test`.`t3`.`c2`) in ( <materialize> (select `test`.`t2i`.`b1`,`test`.`t2i`.`b2` from `test`.`t2i` where (`test`.`t2i`.`b2` > '0') ), <primary_index_lookup>(`test`.`t3`.`c1` in <temporary table> on distinct_key where ((`test`.`t3`.`c1` = `<subquery5>`.`b1`) and (`test`.`t3`.`c2` = `<subquery5>`.`b2`)))))) ), <primary_index_lookup>(`test`.`t1`.`a1` in <temporary table> on distinct_key where ((`test`.`t1`.`a1` = `<subquery4>`.`c1`) and (`test`.`t1`.`a2` = `<subquery4>`.`c2`)))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1
where (a1, a2) in (select * from t1 where a1 > '0' UNION select * from t2 where b1 < '9') and
(a1, a2) in (select c1, c2 from t3
where (c1, c2) in (select b1, b2 from t2i where b2 > '0'));
a1 a2
1 - 01 2 - 01
1 - 02 2 - 02
explain extended
select * from t1, t3
where (a1, a2) in (select * from t1 where a1 > '0' UNION select * from t2 where b1 < '9') and
(c1, c2) in (select c1, c2 from t3
where (c1, c2) in (select b1, b2 from t2i where b2 > '0')) and
a1 = c1;
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
MWL#128: Added into EXPLAIN output info about types of the used join buffers and about the employed join algorithms. Refactored constructors of the JOIN_CACHE* classes.
2010-10-18 13:33:05 -07:00
1 PRIMARY t3 ALL NULL NULL NULL NULL 4 100.00 Using where; Using join buffer (flat, BNL join)
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
4 MATERIALIZED t3 ALL NULL NULL NULL NULL 4 100.00 Using where
5 MATERIALIZED t2i index it2i2 it2i3 18 NULL 5 100.00 Using where; Using index
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
2 DEPENDENT SUBQUERY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
3 DEPENDENT UNION t2 ALL NULL NULL NULL NULL 5 100.00 Using where
NULL UNION RESULT <union2,3> ALL NULL NULL NULL NULL NULL NULL
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2`,`test`.`t3`.`c1` AS `c1`,`test`.`t3`.`c2` AS `c2` from `test`.`t1` join `test`.`t3` where ((`test`.`t3`.`c1` = `test`.`t1`.`a1`) and <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),<exists>(select `test`.`t1`.`a1`,`test`.`t1`.`a2` from `test`.`t1` where ((`test`.`t1`.`a1` > '0') and (<cache>(`test`.`t1`.`a1`) = `test`.`t1`.`a1`) and (<cache>(`test`.`t1`.`a2`) = `test`.`t1`.`a2`)) union select `test`.`t2`.`b1`,`test`.`t2`.`b2` from `test`.`t2` where ((`test`.`t2`.`b1` < '9') and (<cache>(`test`.`t1`.`a1`) = `test`.`t2`.`b1`) and (<cache>(`test`.`t1`.`a2`) = `test`.`t2`.`b2`))))) and <expr_cache><`test`.`t3`.`c1`,`test`.`t3`.`c2`>(<in_optimizer>((`test`.`t3`.`c1`,`test`.`t3`.`c2`),(`test`.`t3`.`c1`,`test`.`t3`.`c2`) in ( <materialize> (select `test`.`t3`.`c1`,`test`.`t3`.`c2` from `test`.`t3` where <expr_cache><`test`.`t3`.`c1`,`test`.`t3`.`c2`>(<in_optimizer>((`test`.`t3`.`c1`,`test`.`t3`.`c2`),(`test`.`t3`.`c1`,`test`.`t3`.`c2`) in ( <materialize> (select `test`.`t2i`.`b1`,`test`.`t2i`.`b2` from `test`.`t2i` where (`test`.`t2i`.`b2` > '0') ), <primary_index_lookup>(`test`.`t3`.`c1` in <temporary table> on distinct_key where ((`test`.`t3`.`c1` = `<subquery5>`.`b1`) and (`test`.`t3`.`c2` = `<subquery5>`.`b2`)))))) ), <primary_index_lookup>(`test`.`t3`.`c1` in <temporary table> on distinct_key where ((`test`.`t3`.`c1` = `<subquery4>`.`c1`) and (`test`.`t3`.`c2` = `<subquery4>`.`c2`)))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1, t3
where (a1, a2) in (select * from t1 where a1 > '0' UNION select * from t2 where b1 < '9') and
(c1, c2) in (select c1, c2 from t3
where (c1, c2) in (select b1, b2 from t2i where b2 > '0')) and
a1 = c1;
a1 a2 c1 c2
1 - 01 2 - 01 1 - 01 2 - 01
1 - 02 2 - 02 1 - 02 2 - 02
/******************************************************************************
* Negative tests, where materialization should not be applied.
******************************************************************************/
# UNION in a subquery
explain extended
select * from t3
where c1 in (select a1 from t1 where a1 > '0' UNION select b1 from t2 where b1 < '9');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t3 ALL NULL NULL NULL NULL 4 100.00 Using where
2 DEPENDENT SUBQUERY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
3 DEPENDENT UNION t2 ALL NULL NULL NULL NULL 5 100.00 Using where
NULL UNION RESULT <union2,3> ALL NULL NULL NULL NULL NULL NULL
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t3`.`c1` AS `c1`,`test`.`t3`.`c2` AS `c2` from `test`.`t3` where <expr_cache><`test`.`t3`.`c1`>(<in_optimizer>(`test`.`t3`.`c1`,<exists>(select `test`.`t1`.`a1` from `test`.`t1` where ((`test`.`t1`.`a1` > '0') and (<cache>(`test`.`t3`.`c1`) = `test`.`t1`.`a1`)) union select `test`.`t2`.`b1` from `test`.`t2` where ((`test`.`t2`.`b1` < '9') and (<cache>(`test`.`t3`.`c1`) = `test`.`t2`.`b1`)))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t3
where c1 in (select a1 from t1 where a1 > '0' UNION select b1 from t2 where b1 < '9');
c1 c2
1 - 01 2 - 01
1 - 02 2 - 02
1 - 03 2 - 03
explain extended
select * from t1
where (a1, a2) in (select b1, b2 from t2
where b2 in (select c2 from t3 t3a where c1 = a1) or
b2 in (select c2 from t3 t3b where c2 LIKE '%03')) and
(a1, a2) in (select c1, c2 from t3 t3c
where (c1, c2) in (select b1, b2 from t2i where b2 > '0' or b2 = a2));
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
5 DEPENDENT SUBQUERY t3c ALL NULL NULL NULL NULL 4 100.00 Using where
6 DEPENDENT SUBQUERY t2i index_subquery it2i1,it2i2,it2i3 it2i3 18 func,func 2 100.00 Using index; Using where
2 DEPENDENT SUBQUERY t2 ALL NULL NULL NULL NULL 5 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
4 MATERIALIZED t3b ALL NULL NULL NULL NULL 4 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
3 DEPENDENT SUBQUERY t3a ALL NULL NULL NULL NULL 4 100.00 Using where
Warnings:
Note 1276 Field or reference 'test.t1.a1' of SELECT #3 was resolved in SELECT #1
Note 1276 Field or reference 'test.t1.a2' of SELECT #6 was resolved in SELECT #1
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where (<expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),<exists>(select `test`.`t2`.`b1`,`test`.`t2`.`b2` from `test`.`t2` where ((<expr_cache><`test`.`t2`.`b2`,`test`.`t1`.`a1`>(<in_optimizer>(`test`.`t2`.`b2`,<exists>(select `test`.`t3a`.`c2` from `test`.`t3` `t3a` where ((`test`.`t3a`.`c1` = `test`.`t1`.`a1`) and (<cache>(`test`.`t2`.`b2`) = `test`.`t3a`.`c2`))))) or <expr_cache><`test`.`t2`.`b2`>(<in_optimizer>(`test`.`t2`.`b2`,`test`.`t2`.`b2` in ( <materialize> (select `test`.`t3b`.`c2` from `test`.`t3` `t3b` where (`test`.`t3b`.`c2` like '%03') ), <primary_index_lookup>(`test`.`t2`.`b2` in <temporary table> on distinct_key where ((`test`.`t2`.`b2` = `<subquery4>`.`c2`))))))) and (<cache>(`test`.`t1`.`a1`) = `test`.`t2`.`b1`) and (<cache>(`test`.`t1`.`a2`) = `test`.`t2`.`b2`))))) and <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),<exists>(select `test`.`t3c`.`c1`,`test`.`t3c`.`c2` from `test`.`t3` `t3c` where (<expr_cache><`test`.`t3c`.`c1`,`test`.`t3c`.`c2`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t3c`.`c1`,`test`.`t3c`.`c2`),<exists>(<index_lookup>(<cache>(`test`.`t3c`.`c1`) in t2i on it2i3 where (((`test`.`t2i`.`b2` > '0') or (`test`.`t2i`.`b2` = `test`.`t1`.`a2`)) and (<cache>(`test`.`t3c`.`c1`) = `test`.`t2i`.`b1`) and (<cache>(`test`.`t3c`.`c2`) = `test`.`t2i`.`b2`)))))) and (<cache>(`test`.`t1`.`a1`) = `test`.`t3c`.`c1`) and (<cache>(`test`.`t1`.`a2`) = `test`.`t3c`.`c2`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
explain extended
select * from t1 where (a1, a2) in (select '1 - 01', '2 - 01');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY NULL NULL NULL NULL NULL NULL NULL NULL No tables used
Warnings:
MDEV-15475: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed on EXPLAIN EXTENDED with constant table and view Print constant ISNULL value independent. Fix of printing of view FRM and CREATE VIEW output
2018-08-06 15:50:22 +02:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),<exists>(select '1 - 01','2 - 01' having (((<cache>(`test`.`t1`.`a1`) = '1 - 01') or isnull(/*always not null*/ 1)) and ((<cache>(`test`.`t1`.`a2`) = '2 - 01') or isnull(/*always not null*/ 1)) and <is_not_null_test>('1 - 01') and <is_not_null_test>('2 - 01')))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1 where (a1, a2) in (select '1 - 01', '2 - 01');
a1 a2
1 - 01 2 - 01
explain extended
select * from t1 where (a1, a2) in (select '1 - 01', '2 - 01' from dual);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY NULL NULL NULL NULL NULL NULL NULL NULL No tables used
Warnings:
MDEV-15475: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed on EXPLAIN EXTENDED with constant table and view Print constant ISNULL value independent. Fix of printing of view FRM and CREATE VIEW output
2018-08-06 15:50:22 +02:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where <expr_cache><`test`.`t1`.`a1`,`test`.`t1`.`a2`>(<in_optimizer>((`test`.`t1`.`a1`,`test`.`t1`.`a2`),<exists>(select '1 - 01','2 - 01' having (((<cache>(`test`.`t1`.`a1`) = '1 - 01') or isnull(/*always not null*/ 1)) and ((<cache>(`test`.`t1`.`a2`) = '2 - 01') or isnull(/*always not null*/ 1)) and <is_not_null_test>('1 - 01') and <is_not_null_test>('2 - 01')))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1 where (a1, a2) in (select '1 - 01', '2 - 01' from dual);
a1 a2
1 - 01 2 - 01
/******************************************************************************
* Subqueries in other uncovered clauses.
******************************************************************************/
/* SELECT clause */
select ((a1,a2) IN (select * from t2 where b2 > '0')) IS NULL from t1;
((a1,a2) IN (select * from t2 where b2 > '0')) IS NULL
0
0
0
/* GROUP BY clause */
create table columns (col int key);
insert into columns values (1), (2);
explain extended
select * from t1 group by (select col from columns limit 1);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00
2 SUBQUERY columns index NULL PRIMARY 4 NULL 2 100.00 Using index
Warnings:
MariaDB 5.2 -> MariaDB 5.3 merge
2010-06-26 14:05:41 +04:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` group by (select `test`.`columns`.`col` from `test`.`columns` limit 1)
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1 group by (select col from columns limit 1);
a1 a2
1 - 00 2 - 00
explain extended
select * from t1 group by (a1 in (select col from columns));
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using temporary; Using filesort
2 DEPENDENT SUBQUERY columns unique_subquery PRIMARY PRIMARY 4 func 1 100.00 Using index; Using where; Full scan on NULL key
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` group by <expr_cache><`test`.`t1`.`a1`>(<in_optimizer>(`test`.`t1`.`a1`,<exists>(<primary_index_lookup>(<cache>(`test`.`t1`.`a1`) in columns on PRIMARY where trigcond((<cache>(`test`.`t1`.`a1`) = `test`.`columns`.`col`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1 group by (a1 in (select col from columns));
a1 a2
1 - 00 2 - 00
/* ORDER BY clause */
explain extended
select * from t1 order by (select col from columns limit 1);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00
2 SUBQUERY columns index NULL PRIMARY 4 NULL 2 100.00 Using index
Warnings:
MariaDB 5.2 -> MariaDB 5.3 merge
2010-06-26 14:05:41 +04:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` order by (select `test`.`columns`.`col` from `test`.`columns` limit 1)
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select * from t1 order by (select col from columns limit 1);
a1 a2
1 - 00 2 - 00
1 - 01 2 - 01
1 - 02 2 - 02
/******************************************************************************
* Column types/sizes that affect materialization.
******************************************************************************/
/*
Test that BLOBs are not materialized (except when arguments of some functions).
*/
# force materialization to be always considered
set @prefix_len = 6;
set @blob_len = 16;
set @suffix_len = @blob_len - @prefix_len;
create table t1_16 (a1 blob(16), a2 blob(16));
create table t2_16 (b1 blob(16), b2 blob(16));
create table t3_16 (c1 blob(16), c2 blob(16));
insert into t1_16 values
(concat('1 - 00', repeat('x', @suffix_len)), concat('2 - 00', repeat('x', @suffix_len)));
insert into t1_16 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t1_16 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t2_16 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t2_16 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t2_16 values
(concat('1 - 03', repeat('x', @suffix_len)), concat('2 - 03', repeat('x', @suffix_len)));
insert into t3_16 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t3_16 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t3_16 values
(concat('1 - 03', repeat('x', @suffix_len)), concat('2 - 03', repeat('x', @suffix_len)));
insert into t3_16 values
(concat('1 - 04', repeat('x', @suffix_len)), concat('2 - 04', repeat('x', @suffix_len)));
explain extended select left(a1,7), left(a2,7)
from t1_16
where a1 in (select b1 from t2_16 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_16 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t2_16 ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_16`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_16`.`a2`,7) AS `left(a2,7)` from `test`.`t1_16` where <expr_cache><`test`.`t1_16`.`a1`>(<in_optimizer>(`test`.`t1_16`.`a1`,<exists>(select `test`.`t2_16`.`b1` from `test`.`t2_16` where ((`test`.`t2_16`.`b1` > '0') and (<cache>(`test`.`t1_16`.`a1`) = `test`.`t2_16`.`b1`)))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_16
where a1 in (select b1 from t2_16 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended select left(a1,7), left(a2,7)
from t1_16
where (a1,a2) in (select b1, b2 from t2_16 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_16 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t2_16 ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_16`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_16`.`a2`,7) AS `left(a2,7)` from `test`.`t1_16` where <expr_cache><`test`.`t1_16`.`a1`,`test`.`t1_16`.`a2`>(<in_optimizer>((`test`.`t1_16`.`a1`,`test`.`t1_16`.`a2`),<exists>(select `test`.`t2_16`.`b1`,`test`.`t2_16`.`b2` from `test`.`t2_16` where ((`test`.`t2_16`.`b1` > '0') and (<cache>(`test`.`t1_16`.`a1`) = `test`.`t2_16`.`b1`) and (<cache>(`test`.`t1_16`.`a2`) = `test`.`t2_16`.`b2`)))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_16
where (a1,a2) in (select b1, b2 from t2_16 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended select left(a1,7), left(a2,7)
from t1_16
where a1 in (select substring(b1,1,16) from t2_16 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_16 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2_16 ALL NULL NULL NULL NULL 3 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_16`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_16`.`a2`,7) AS `left(a2,7)` from `test`.`t1_16` where <expr_cache><`test`.`t1_16`.`a1`>(<in_optimizer>(`test`.`t1_16`.`a1`,`test`.`t1_16`.`a1` in ( <materialize> (select substr(`test`.`t2_16`.`b1`,1,16) from `test`.`t2_16` where (`test`.`t2_16`.`b1` > '0') ), <primary_index_lookup>(`test`.`t1_16`.`a1` in <temporary table> on distinct_key where ((`test`.`t1_16`.`a1` = `<subquery2>`.`substring(b1,1,16)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_16
where a1 in (select substring(b1,1,16) from t2_16 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended select left(a1,7), left(a2,7)
from t1_16
where a1 in (select group_concat(b1) from t2_16 group by b2);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_16 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t2_16 ALL NULL NULL NULL NULL 3 100.00 Using filesort
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_16`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_16`.`a2`,7) AS `left(a2,7)` from `test`.`t1_16` where <expr_cache><`test`.`t1_16`.`a1`>(<in_optimizer>(`test`.`t1_16`.`a1`,<exists>(select group_concat(`test`.`t2_16`.`b1` separator ',') from `test`.`t2_16` group by `test`.`t2_16`.`b2` having (<cache>(`test`.`t1_16`.`a1`) = <ref_null_helper>(group_concat(`test`.`t2_16`.`b1` separator ','))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_16
where a1 in (select group_concat(b1) from t2_16 group by b2);
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
set @@group_concat_max_len = 256;
explain extended select left(a1,7), left(a2,7)
from t1_16
where a1 in (select group_concat(b1) from t2_16 group by b2);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_16 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2_16 ALL NULL NULL NULL NULL 3 100.00 Using filesort
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_16`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_16`.`a2`,7) AS `left(a2,7)` from `test`.`t1_16` where <expr_cache><`test`.`t1_16`.`a1`>(<in_optimizer>(`test`.`t1_16`.`a1`,`test`.`t1_16`.`a1` in ( <materialize> (select group_concat(`test`.`t2_16`.`b1` separator ',') from `test`.`t2_16` group by `test`.`t2_16`.`b2` ), <primary_index_lookup>(`test`.`t1_16`.`a1` in <temporary table> on distinct_key where ((`test`.`t1_16`.`a1` = `<subquery2>`.`group_concat(b1)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_16
where a1 in (select group_concat(b1) from t2_16 group by b2);
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended
select * from t1
where concat(a1,'x') IN
(select left(a1,8) from t1_16
where (a1, a2) IN
(select t2_16.b1, t2_16.b2 from t2_16, t2
where t2.b2 = substring(t2_16.b2,1,6) and
t2.b1 IN (select c1 from t3 where c2 > '0')));
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t1_16 ALL NULL NULL NULL NULL 3 100.00 Using where
3 DEPENDENT SUBQUERY t2_16 ALL NULL NULL NULL NULL 3 100.00 Using where
MWL#128: Added into EXPLAIN output info about types of the used join buffers and about the employed join algorithms. Refactored constructors of the JOIN_CACHE* classes.
2010-10-18 13:33:05 -07:00
3 DEPENDENT SUBQUERY t2 ALL NULL NULL NULL NULL 5 100.00 Using where; Using join buffer (flat, BNL join)
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
4 MATERIALIZED t3 ALL NULL NULL NULL NULL 4 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a1` AS `a1`,`test`.`t1`.`a2` AS `a2` from `test`.`t1` where <expr_cache><concat(`test`.`t1`.`a1`,'x')>(<in_optimizer>(concat(`test`.`t1`.`a1`,'x'),<exists>(select left(`test`.`t1_16`.`a1`,8) from `test`.`t1_16` where (<expr_cache><`test`.`t1_16`.`a1`,`test`.`t1_16`.`a2`>(<in_optimizer>((`test`.`t1_16`.`a1`,`test`.`t1_16`.`a2`),<exists>(select `test`.`t2_16`.`b1`,`test`.`t2_16`.`b2` from `test`.`t2_16` join `test`.`t2` where ((`test`.`t2`.`b2` = substr(`test`.`t2_16`.`b2`,1,6)) and <expr_cache><`test`.`t2`.`b1`>(<in_optimizer>(`test`.`t2`.`b1`,`test`.`t2`.`b1` in ( <materialize> (select `test`.`t3`.`c1` from `test`.`t3` where (`test`.`t3`.`c2` > '0') ), <primary_index_lookup>(`test`.`t2`.`b1` in <temporary table> on distinct_key where ((`test`.`t2`.`b1` = `<subquery4>`.`c1`)))))) and (<cache>(`test`.`t1_16`.`a1`) = `test`.`t2_16`.`b1`) and (<cache>(`test`.`t1_16`.`a2`) = `test`.`t2_16`.`b2`))))) and (<cache>(concat(`test`.`t1`.`a1`,'x')) = left(`test`.`t1_16`.`a1`,8))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
drop table t1_16, t2_16, t3_16;
set @blob_len = 512;
set @suffix_len = @blob_len - @prefix_len;
create table t1_512 (a1 blob(512), a2 blob(512));
create table t2_512 (b1 blob(512), b2 blob(512));
create table t3_512 (c1 blob(512), c2 blob(512));
insert into t1_512 values
(concat('1 - 00', repeat('x', @suffix_len)), concat('2 - 00', repeat('x', @suffix_len)));
insert into t1_512 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t1_512 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t2_512 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t2_512 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t2_512 values
(concat('1 - 03', repeat('x', @suffix_len)), concat('2 - 03', repeat('x', @suffix_len)));
insert into t3_512 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t3_512 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t3_512 values
(concat('1 - 03', repeat('x', @suffix_len)), concat('2 - 03', repeat('x', @suffix_len)));
insert into t3_512 values
(concat('1 - 04', repeat('x', @suffix_len)), concat('2 - 04', repeat('x', @suffix_len)));
explain extended select left(a1,7), left(a2,7)
from t1_512
where a1 in (select b1 from t2_512 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_512 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t2_512 ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_512`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_512`.`a2`,7) AS `left(a2,7)` from `test`.`t1_512` where <expr_cache><`test`.`t1_512`.`a1`>(<in_optimizer>(`test`.`t1_512`.`a1`,<exists>(select `test`.`t2_512`.`b1` from `test`.`t2_512` where ((`test`.`t2_512`.`b1` > '0') and (<cache>(`test`.`t1_512`.`a1`) = `test`.`t2_512`.`b1`)))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_512
where a1 in (select b1 from t2_512 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended select left(a1,7), left(a2,7)
from t1_512
where (a1,a2) in (select b1, b2 from t2_512 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_512 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t2_512 ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_512`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_512`.`a2`,7) AS `left(a2,7)` from `test`.`t1_512` where <expr_cache><`test`.`t1_512`.`a1`,`test`.`t1_512`.`a2`>(<in_optimizer>((`test`.`t1_512`.`a1`,`test`.`t1_512`.`a2`),<exists>(select `test`.`t2_512`.`b1`,`test`.`t2_512`.`b2` from `test`.`t2_512` where ((`test`.`t2_512`.`b1` > '0') and (<cache>(`test`.`t1_512`.`a1`) = `test`.`t2_512`.`b1`) and (<cache>(`test`.`t1_512`.`a2`) = `test`.`t2_512`.`b2`)))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_512
where (a1,a2) in (select b1, b2 from t2_512 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended select left(a1,7), left(a2,7)
from t1_512
where a1 in (select substring(b1,1,512) from t2_512 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_512 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2_512 ALL NULL NULL NULL NULL 3 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_512`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_512`.`a2`,7) AS `left(a2,7)` from `test`.`t1_512` where <expr_cache><`test`.`t1_512`.`a1`>(<in_optimizer>(`test`.`t1_512`.`a1`,`test`.`t1_512`.`a1` in ( <materialize> (select substr(`test`.`t2_512`.`b1`,1,512) from `test`.`t2_512` where (`test`.`t2_512`.`b1` > '0') ), <primary_index_lookup>(`test`.`t1_512`.`a1` in <temporary table> on distinct_key where ((`test`.`t1_512`.`a1` = `<subquery2>`.`substring(b1,1,512)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_512
where a1 in (select substring(b1,1,512) from t2_512 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended select left(a1,7), left(a2,7)
from t1_512
where a1 in (select group_concat(b1) from t2_512 group by b2);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_512 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2_512 ALL NULL NULL NULL NULL 3 100.00 Using filesort
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_512`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_512`.`a2`,7) AS `left(a2,7)` from `test`.`t1_512` where <expr_cache><`test`.`t1_512`.`a1`>(<in_optimizer>(`test`.`t1_512`.`a1`,`test`.`t1_512`.`a1` in ( <materialize> (select group_concat(`test`.`t2_512`.`b1` separator ',') from `test`.`t2_512` group by `test`.`t2_512`.`b2` ), <primary_index_lookup>(`test`.`t1_512`.`a1` in <temporary table> on distinct_key where ((`test`.`t1_512`.`a1` = `<subquery2>`.`group_concat(b1)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_512
where a1 in (select group_concat(b1) from t2_512 group by b2);
left(a1,7) left(a2,7)
set @@group_concat_max_len = 256;
explain extended select left(a1,7), left(a2,7)
from t1_512
where a1 in (select group_concat(b1) from t2_512 group by b2);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_512 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2_512 ALL NULL NULL NULL NULL 3 100.00 Using filesort
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_512`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_512`.`a2`,7) AS `left(a2,7)` from `test`.`t1_512` where <expr_cache><`test`.`t1_512`.`a1`>(<in_optimizer>(`test`.`t1_512`.`a1`,`test`.`t1_512`.`a1` in ( <materialize> (select group_concat(`test`.`t2_512`.`b1` separator ',') from `test`.`t2_512` group by `test`.`t2_512`.`b2` ), <primary_index_lookup>(`test`.`t1_512`.`a1` in <temporary table> on distinct_key where ((`test`.`t1_512`.`a1` = `<subquery2>`.`group_concat(b1)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_512
where a1 in (select group_concat(b1) from t2_512 group by b2);
left(a1,7) left(a2,7)
drop table t1_512, t2_512, t3_512;
set @blob_len = 1024;
set @suffix_len = @blob_len - @prefix_len;
create table t1_1024 (a1 blob(1024), a2 blob(1024));
create table t2_1024 (b1 blob(1024), b2 blob(1024));
create table t3_1024 (c1 blob(1024), c2 blob(1024));
insert into t1_1024 values
(concat('1 - 00', repeat('x', @suffix_len)), concat('2 - 00', repeat('x', @suffix_len)));
insert into t1_1024 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t1_1024 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t2_1024 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t2_1024 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t2_1024 values
(concat('1 - 03', repeat('x', @suffix_len)), concat('2 - 03', repeat('x', @suffix_len)));
insert into t3_1024 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t3_1024 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t3_1024 values
(concat('1 - 03', repeat('x', @suffix_len)), concat('2 - 03', repeat('x', @suffix_len)));
insert into t3_1024 values
(concat('1 - 04', repeat('x', @suffix_len)), concat('2 - 04', repeat('x', @suffix_len)));
explain extended select left(a1,7), left(a2,7)
from t1_1024
where a1 in (select b1 from t2_1024 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_1024 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t2_1024 ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_1024`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_1024`.`a2`,7) AS `left(a2,7)` from `test`.`t1_1024` where <expr_cache><`test`.`t1_1024`.`a1`>(<in_optimizer>(`test`.`t1_1024`.`a1`,<exists>(select `test`.`t2_1024`.`b1` from `test`.`t2_1024` where ((`test`.`t2_1024`.`b1` > '0') and (<cache>(`test`.`t1_1024`.`a1`) = `test`.`t2_1024`.`b1`)))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_1024
where a1 in (select b1 from t2_1024 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended select left(a1,7), left(a2,7)
from t1_1024
where (a1,a2) in (select b1, b2 from t2_1024 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_1024 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t2_1024 ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_1024`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_1024`.`a2`,7) AS `left(a2,7)` from `test`.`t1_1024` where <expr_cache><`test`.`t1_1024`.`a1`,`test`.`t1_1024`.`a2`>(<in_optimizer>((`test`.`t1_1024`.`a1`,`test`.`t1_1024`.`a2`),<exists>(select `test`.`t2_1024`.`b1`,`test`.`t2_1024`.`b2` from `test`.`t2_1024` where ((`test`.`t2_1024`.`b1` > '0') and (<cache>(`test`.`t1_1024`.`a1`) = `test`.`t2_1024`.`b1`) and (<cache>(`test`.`t1_1024`.`a2`) = `test`.`t2_1024`.`b2`)))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_1024
where (a1,a2) in (select b1, b2 from t2_1024 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended select left(a1,7), left(a2,7)
from t1_1024
where a1 in (select substring(b1,1,1024) from t2_1024 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_1024 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t2_1024 ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_1024`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_1024`.`a2`,7) AS `left(a2,7)` from `test`.`t1_1024` where <expr_cache><`test`.`t1_1024`.`a1`>(<in_optimizer>(`test`.`t1_1024`.`a1`,<exists>(select substr(`test`.`t2_1024`.`b1`,1,1024) from `test`.`t2_1024` where ((`test`.`t2_1024`.`b1` > '0') and (<cache>(`test`.`t1_1024`.`a1`) = substr(`test`.`t2_1024`.`b1`,1,1024))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_1024
where a1 in (select substring(b1,1,1024) from t2_1024 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended select left(a1,7), left(a2,7)
from t1_1024
where a1 in (select group_concat(b1) from t2_1024 group by b2);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_1024 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2_1024 ALL NULL NULL NULL NULL 3 100.00 Using filesort
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_1024`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_1024`.`a2`,7) AS `left(a2,7)` from `test`.`t1_1024` where <expr_cache><`test`.`t1_1024`.`a1`>(<in_optimizer>(`test`.`t1_1024`.`a1`,`test`.`t1_1024`.`a1` in ( <materialize> (select group_concat(`test`.`t2_1024`.`b1` separator ',') from `test`.`t2_1024` group by `test`.`t2_1024`.`b2` ), <primary_index_lookup>(`test`.`t1_1024`.`a1` in <temporary table> on distinct_key where ((`test`.`t1_1024`.`a1` = `<subquery2>`.`group_concat(b1)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_1024
where a1 in (select group_concat(b1) from t2_1024 group by b2);
left(a1,7) left(a2,7)
set @@group_concat_max_len = 256;
explain extended select left(a1,7), left(a2,7)
from t1_1024
where a1 in (select group_concat(b1) from t2_1024 group by b2);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_1024 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2_1024 ALL NULL NULL NULL NULL 3 100.00 Using filesort
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_1024`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_1024`.`a2`,7) AS `left(a2,7)` from `test`.`t1_1024` where <expr_cache><`test`.`t1_1024`.`a1`>(<in_optimizer>(`test`.`t1_1024`.`a1`,`test`.`t1_1024`.`a1` in ( <materialize> (select group_concat(`test`.`t2_1024`.`b1` separator ',') from `test`.`t2_1024` group by `test`.`t2_1024`.`b2` ), <primary_index_lookup>(`test`.`t1_1024`.`a1` in <temporary table> on distinct_key where ((`test`.`t1_1024`.`a1` = `<subquery2>`.`group_concat(b1)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_1024
where a1 in (select group_concat(b1) from t2_1024 group by b2);
left(a1,7) left(a2,7)
drop table t1_1024, t2_1024, t3_1024;
set @blob_len = 1025;
set @suffix_len = @blob_len - @prefix_len;
create table t1_1025 (a1 blob(1025), a2 blob(1025));
create table t2_1025 (b1 blob(1025), b2 blob(1025));
create table t3_1025 (c1 blob(1025), c2 blob(1025));
insert into t1_1025 values
(concat('1 - 00', repeat('x', @suffix_len)), concat('2 - 00', repeat('x', @suffix_len)));
insert into t1_1025 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t1_1025 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t2_1025 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t2_1025 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t2_1025 values
(concat('1 - 03', repeat('x', @suffix_len)), concat('2 - 03', repeat('x', @suffix_len)));
insert into t3_1025 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t3_1025 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t3_1025 values
(concat('1 - 03', repeat('x', @suffix_len)), concat('2 - 03', repeat('x', @suffix_len)));
insert into t3_1025 values
(concat('1 - 04', repeat('x', @suffix_len)), concat('2 - 04', repeat('x', @suffix_len)));
explain extended select left(a1,7), left(a2,7)
from t1_1025
where a1 in (select b1 from t2_1025 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_1025 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t2_1025 ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_1025`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_1025`.`a2`,7) AS `left(a2,7)` from `test`.`t1_1025` where <expr_cache><`test`.`t1_1025`.`a1`>(<in_optimizer>(`test`.`t1_1025`.`a1`,<exists>(select `test`.`t2_1025`.`b1` from `test`.`t2_1025` where ((`test`.`t2_1025`.`b1` > '0') and (<cache>(`test`.`t1_1025`.`a1`) = `test`.`t2_1025`.`b1`)))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_1025
where a1 in (select b1 from t2_1025 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended select left(a1,7), left(a2,7)
from t1_1025
where (a1,a2) in (select b1, b2 from t2_1025 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_1025 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t2_1025 ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_1025`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_1025`.`a2`,7) AS `left(a2,7)` from `test`.`t1_1025` where <expr_cache><`test`.`t1_1025`.`a1`,`test`.`t1_1025`.`a2`>(<in_optimizer>((`test`.`t1_1025`.`a1`,`test`.`t1_1025`.`a2`),<exists>(select `test`.`t2_1025`.`b1`,`test`.`t2_1025`.`b2` from `test`.`t2_1025` where ((`test`.`t2_1025`.`b1` > '0') and (<cache>(`test`.`t1_1025`.`a1`) = `test`.`t2_1025`.`b1`) and (<cache>(`test`.`t1_1025`.`a2`) = `test`.`t2_1025`.`b2`)))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_1025
where (a1,a2) in (select b1, b2 from t2_1025 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended select left(a1,7), left(a2,7)
from t1_1025
where a1 in (select substring(b1,1,1025) from t2_1025 where b1 > '0');
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_1025 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t2_1025 ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_1025`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_1025`.`a2`,7) AS `left(a2,7)` from `test`.`t1_1025` where <expr_cache><`test`.`t1_1025`.`a1`>(<in_optimizer>(`test`.`t1_1025`.`a1`,<exists>(select substr(`test`.`t2_1025`.`b1`,1,1025) from `test`.`t2_1025` where ((`test`.`t2_1025`.`b1` > '0') and (<cache>(`test`.`t1_1025`.`a1`) = substr(`test`.`t2_1025`.`b1`,1,1025))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_1025
where a1 in (select substring(b1,1,1025) from t2_1025 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
1 - 02x 2 - 02x
explain extended select left(a1,7), left(a2,7)
from t1_1025
where a1 in (select group_concat(b1) from t2_1025 group by b2);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_1025 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2_1025 ALL NULL NULL NULL NULL 3 100.00 Using filesort
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_1025`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_1025`.`a2`,7) AS `left(a2,7)` from `test`.`t1_1025` where <expr_cache><`test`.`t1_1025`.`a1`>(<in_optimizer>(`test`.`t1_1025`.`a1`,`test`.`t1_1025`.`a1` in ( <materialize> (select group_concat(`test`.`t2_1025`.`b1` separator ',') from `test`.`t2_1025` group by `test`.`t2_1025`.`b2` ), <primary_index_lookup>(`test`.`t1_1025`.`a1` in <temporary table> on distinct_key where ((`test`.`t1_1025`.`a1` = `<subquery2>`.`group_concat(b1)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_1025
where a1 in (select group_concat(b1) from t2_1025 group by b2);
left(a1,7) left(a2,7)
set @@group_concat_max_len = 256;
explain extended select left(a1,7), left(a2,7)
from t1_1025
where a1 in (select group_concat(b1) from t2_1025 group by b2);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1_1025 ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2_1025 ALL NULL NULL NULL NULL 3 100.00 Using filesort
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select left(`test`.`t1_1025`.`a1`,7) AS `left(a1,7)`,left(`test`.`t1_1025`.`a2`,7) AS `left(a2,7)` from `test`.`t1_1025` where <expr_cache><`test`.`t1_1025`.`a1`>(<in_optimizer>(`test`.`t1_1025`.`a1`,`test`.`t1_1025`.`a1` in ( <materialize> (select group_concat(`test`.`t2_1025`.`b1` separator ',') from `test`.`t2_1025` group by `test`.`t2_1025`.`b2` ), <primary_index_lookup>(`test`.`t1_1025`.`a1` in <temporary table> on distinct_key where ((`test`.`t1_1025`.`a1` = `<subquery2>`.`group_concat(b1)`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select left(a1,7), left(a2,7)
from t1_1025
where a1 in (select group_concat(b1) from t2_1025 group by b2);
left(a1,7) left(a2,7)
drop table t1_1025, t2_1025, t3_1025;
create table t1bit (a1 bit(3), a2 bit(3));
create table t2bit (b1 bit(3), b2 bit(3));
insert into t1bit values (b'000', b'100');
insert into t1bit values (b'001', b'101');
insert into t1bit values (b'010', b'110');
insert into t2bit values (b'001', b'101');
insert into t2bit values (b'010', b'110');
insert into t2bit values (b'110', b'111');
explain extended select bin(a1), bin(a2)
from t1bit
where (a1, a2) in (select b1, b2 from t2bit);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1bit ALL NULL NULL NULL NULL 3 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2bit ALL NULL NULL NULL NULL 3 100.00
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select conv(`test`.`t1bit`.`a1`,10,2) AS `bin(a1)`,conv(`test`.`t1bit`.`a2`,10,2) AS `bin(a2)` from `test`.`t1bit` where <expr_cache><`test`.`t1bit`.`a1`,`test`.`t1bit`.`a2`>(<in_optimizer>((`test`.`t1bit`.`a1`,`test`.`t1bit`.`a2`),(`test`.`t1bit`.`a1`,`test`.`t1bit`.`a2`) in ( <materialize> (select `test`.`t2bit`.`b1`,`test`.`t2bit`.`b2` from `test`.`t2bit` ), <primary_index_lookup>(`test`.`t1bit`.`a1` in <temporary table> on distinct_key where ((`test`.`t1bit`.`a1` = `<subquery2>`.`b1`) and (`test`.`t1bit`.`a2` = `<subquery2>`.`b2`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select bin(a1), bin(a2)
from t1bit
where (a1, a2) in (select b1, b2 from t2bit);
bin(a1) bin(a2)
1 101
10 110
drop table t1bit, t2bit;
create table t1bb (a1 bit(3), a2 blob(3));
create table t2bb (b1 bit(3), b2 blob(3));
insert into t1bb values (b'000', '100');
insert into t1bb values (b'001', '101');
insert into t1bb values (b'010', '110');
insert into t2bb values (b'001', '101');
insert into t2bb values (b'010', '110');
insert into t2bb values (b'110', '111');
explain extended select bin(a1), a2
from t1bb
where (a1, a2) in (select b1, b2 from t2bb);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1bb ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t2bb ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select conv(`test`.`t1bb`.`a1`,10,2) AS `bin(a1)`,`test`.`t1bb`.`a2` AS `a2` from `test`.`t1bb` where <expr_cache><`test`.`t1bb`.`a1`,`test`.`t1bb`.`a2`>(<in_optimizer>((`test`.`t1bb`.`a1`,`test`.`t1bb`.`a2`),<exists>(select `test`.`t2bb`.`b1`,`test`.`t2bb`.`b2` from `test`.`t2bb` where ((<cache>(`test`.`t1bb`.`a1`) = `test`.`t2bb`.`b1`) and (<cache>(`test`.`t1bb`.`a2`) = `test`.`t2bb`.`b2`)))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select bin(a1), a2
from t1bb
where (a1, a2) in (select b1, b2 from t2bb);
bin(a1) a2
1 101
10 110
drop table t1bb, t2bb;
drop table t1, t2, t3, t1i, t2i, t3i, columns;
/******************************************************************************
* Test the cache of the left operand of IN.
******************************************************************************/
Post-merge fix for tests - bad .result merge - make .test file do not switch off both materialization and IN->EXISTS as that leads to error now.
2011-05-29 00:51:26 +04:00
# Test that default values of Cached_item are not used for comparison
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
create table t1 (s1 int);
create table t2 (s2 int);
insert into t1 values (5),(1),(0);
insert into t2 values (0), (1);
select s2 from t2 where s2 in (select s1 from t1);
s2
0
1
drop table t1, t2;
create table t1 (a int not null, b int not null);
create table t2 (c int not null, d int not null);
create table t3 (e int not null);
insert into t1 values (1,10);
insert into t1 values (1,20);
insert into t1 values (2,10);
insert into t1 values (2,20);
insert into t1 values (2,30);
insert into t1 values (3,20);
insert into t1 values (4,40);
insert into t2 values (2,10);
insert into t2 values (2,20);
insert into t2 values (2,40);
insert into t2 values (3,20);
insert into t2 values (4,10);
insert into t2 values (5,10);
insert into t3 values (10);
insert into t3 values (10);
insert into t3 values (20);
insert into t3 values (30);
explain extended
select a from t1 where a in (select c from t2 where d >= 20);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 7 100.00 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 6 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where <expr_cache><`test`.`t1`.`a`>(<in_optimizer>(`test`.`t1`.`a`,`test`.`t1`.`a` in ( <materialize> (select `test`.`t2`.`c` from `test`.`t2` where (`test`.`t2`.`d` >= 20) ), <primary_index_lookup>(`test`.`t1`.`a` in <temporary table> on distinct_key where ((`test`.`t1`.`a` = `<subquery2>`.`c`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select a from t1 where a in (select c from t2 where d >= 20);
a
2
2
2
3
create index it1a on t1(a);
explain extended
select a from t1 where a in (select c from t2 where d >= 20);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 index NULL it1a 4 NULL 7 100.00 Using where; Using index
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 6 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where <expr_cache><`test`.`t1`.`a`>(<in_optimizer>(`test`.`t1`.`a`,`test`.`t1`.`a` in ( <materialize> (select `test`.`t2`.`c` from `test`.`t2` where (`test`.`t2`.`d` >= 20) ), <primary_index_lookup>(`test`.`t1`.`a` in <temporary table> on distinct_key where ((`test`.`t1`.`a` = `<subquery2>`.`c`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select a from t1 where a in (select c from t2 where d >= 20);
a
2
2
2
3
insert into t2 values (1,10);
explain extended
select a from t1 where a in (select c from t2 where d >= 20);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 index NULL it1a 4 NULL 7 100.00 Using where; Using index
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 7 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where <expr_cache><`test`.`t1`.`a`>(<in_optimizer>(`test`.`t1`.`a`,`test`.`t1`.`a` in ( <materialize> (select `test`.`t2`.`c` from `test`.`t2` where (`test`.`t2`.`d` >= 20) ), <primary_index_lookup>(`test`.`t1`.`a` in <temporary table> on distinct_key where ((`test`.`t1`.`a` = `<subquery2>`.`c`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select a from t1 where a in (select c from t2 where d >= 20);
a
2
2
2
3
explain extended
select a from t1 group by a having a in (select c from t2 where d >= 20);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 index NULL it1a 4 NULL 7 100.00 Using index
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 7 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` group by `test`.`t1`.`a` having <expr_cache><`test`.`t1`.`a`>(<in_optimizer>(`test`.`t1`.`a`,`test`.`t1`.`a` in ( <materialize> (select `test`.`t2`.`c` from `test`.`t2` where (`test`.`t2`.`d` >= 20) ), <primary_index_lookup>(`test`.`t1`.`a` in <temporary table> on distinct_key where ((`test`.`t1`.`a` = `<subquery2>`.`c`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select a from t1 group by a having a in (select c from t2 where d >= 20);
a
2
3
create index iab on t1(a, b);
explain extended
select a from t1 group by a having a in (select c from t2 where d >= 20);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 index NULL it1a 4 NULL 7 100.00 Using index
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 7 100.00 Using where
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
Warnings:
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` group by `test`.`t1`.`a` having <expr_cache><`test`.`t1`.`a`>(<in_optimizer>(`test`.`t1`.`a`,`test`.`t1`.`a` in ( <materialize> (select `test`.`t2`.`c` from `test`.`t2` where (`test`.`t2`.`d` >= 20) ), <primary_index_lookup>(`test`.`t1`.`a` in <temporary table> on distinct_key where ((`test`.`t1`.`a` = `<subquery2>`.`c`))))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select a from t1 group by a having a in (select c from t2 where d >= 20);
a
2
3
explain extended
select a from t1 group by a
having a in (select c from t2 where d >= some(select e from t3 where max(b)=e));
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 index NULL iab 8 NULL 7 100.00 Using index
2 DEPENDENT SUBQUERY t2 ALL NULL NULL NULL NULL 7 100.00 Using where
3 DEPENDENT SUBQUERY t3 ALL NULL NULL NULL NULL 4 100.00 Using where
Warnings:
Note 1276 Field or reference 'test.t1.b' of SELECT #3 was resolved in SELECT #1
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` group by `test`.`t1`.`a` having <expr_cache><`test`.`t1`.`a`,`test`.`t1`.`b`,max(`test`.`t1`.`b`),max(`test`.`t1`.`b`)>(<in_optimizer>(`test`.`t1`.`a`,<exists>(select `test`.`t2`.`c` from `test`.`t2` where (<nop>(<expr_cache><`test`.`t2`.`d`,`test`.`t1`.`b`,max(`test`.`t1`.`b`),max(`test`.`t1`.`b`)>(<in_optimizer>(`test`.`t2`.`d`,<exists>(select `test`.`t3`.`e` from `test`.`t3` where (max(`test`.`t1`.`b`) = `test`.`t3`.`e`) having (<cache>(`test`.`t2`.`d`) >= <ref_null_helper>(`test`.`t3`.`e`)))))) and (<cache>(`test`.`t1`.`a`) = `test`.`t2`.`c`)))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select a from t1 group by a
having a in (select c from t2 where d >= some(select e from t3 where max(b)=e));
a
2
3
explain extended
select a from t1
where a in (select c from t2 where d >= some(select e from t3 where b=e));
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 index NULL iab 8 NULL 7 100.00 Using where; Using index
2 DEPENDENT SUBQUERY t2 ALL NULL NULL NULL NULL 7 100.00 Using where
3 DEPENDENT SUBQUERY t3 ALL NULL NULL NULL NULL 4 100.00 Using where
Warnings:
Note 1276 Field or reference 'test.t1.b' of SELECT #3 was resolved in SELECT #1
Making subquery cache on by default.
2011-10-05 18:18:00 +03:00
Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where <expr_cache><`test`.`t1`.`a`,`test`.`t1`.`b`>(<in_optimizer>(`test`.`t1`.`a`,<exists>(select `test`.`t2`.`c` from `test`.`t2` where (<nop>(<expr_cache><`test`.`t2`.`d`,`test`.`t1`.`b`>(<in_optimizer>(`test`.`t2`.`d`,<exists>(select `test`.`t3`.`e` from `test`.`t3` where ((`test`.`t1`.`b` = `test`.`t3`.`e`) and (<cache>(`test`.`t2`.`d`) >= `test`.`t3`.`e`)))))) and (<cache>(`test`.`t1`.`a`) = `test`.`t2`.`c`)))))
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select a from t1
where a in (select c from t2 where d >= some(select e from t3 where b=e));
a
1
2
2
2
3
drop table t1, t2, t3;
create table t2 (a int, b int, key(a), key(b));
insert into t2 values (3,3),(3,3),(3,3);
select 1 from t2 where
t2.a > 1
or
t2.a = 3 and not t2.a not in (select t2.b from t2);
1
1
1
1
drop table t2;
create table t1 (a1 int key);
create table t2 (b1 int);
insert into t1 values (5);
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
explain select min(a1) from t1 where 7 in (select max(b1) from t2 group by b1);
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
id select_type table type possible_keys key key_len ref rows Extra
Merged the fix for bug lp:944706, mdev-193
2012-06-19 15:06:45 +03:00
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL Impossible WHERE
Fix for bug lp:944706, task MDEV-193 The patch enables back constant subquery execution during query optimization after it was disabled during the development of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION). The main idea is that constant subqueries are allowed to be executed during optimization if their execution is not expensive. The approach is as follows: - Constant subqueries are recursively optimized in the beginning of JOIN::optimize of the outer query. This is done by the new method JOIN::optimize_constant_subqueries(). This is done so that the cost of executing these queries can be estimated. - Optimization of the outer query proceeds normally. During this phase the optimizer may request execution of non-expensive constant subqueries. Each place where the optimizer may potentially execute an expensive expression is guarded with the predicate Item::is_expensive(). - The implementation of Item_subselect::is_expensive has been extended to use the number of examined rows (estimated by the optimizer) as a way to determine whether the subquery is expensive or not. - The new system variable "expensive_subquery_limit" controls how many examined rows are considered to be not expensive. The default is 100. In addition, multiple changes were needed to make this solution work in the light of the changes made by MWL#89. These changes were needed to fix various crashes and wrong results, and legacy bugs discovered during development.
2012-05-17 13:46:05 +03:00
2 MATERIALIZED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
select min(a1) from t1 where 7 in (select max(b1) from t2 group by b1);
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
min(a1)
Fixed LP bug #702301. The function matching_cond should take into account that there may be always false constant conjunctive conditions that has not been evaluated yet,for example, conjunctive conditions with non-correlated subqueries.
2011-07-20 16:09:28 -07:00
NULL
Post-merge fix for tests - bad .result merge - make .test file do not switch off both materialization and IN->EXISTS as that leads to error now.
2011-05-29 00:51:26 +04:00
set @save_optimizer_switch=@@optimizer_switch;
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @@optimizer_switch=@optimizer_switch_local_default;
set @@optimizer_switch='materialization=off,in_to_exists=on';
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
explain select min(a1) from t1 where 7 in (select max(b1) from t2 group by b1);
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
id select_type table type possible_keys key key_len ref rows Extra
Merged the fix for bug lp:944706, mdev-193
2012-06-19 15:06:45 +03:00
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL Impossible WHERE
Patch for mdev-287: CHEAP SQ: A query with subquery in SELECT list, EXISTS, inner joins takes hundreds times longer Analysis: The fix for lp:944706 introduces early subquery optimization. While a subquery is being optimized some of its predicates may be removed. In the test case, the EXISTS subquery is constant, and is evaluated to TRUE. As a result the whole OR is TRUE, and thus the correlated condition "b = alias1.b" is optimized away. The subquery becomes non-correlated. The subquery cache is designed to work only for correlated subqueries. If constant subquery optimization is disallowed, then the constant subquery is not evaluated, the subquery remains correlated, and its execution is cached. As a result execution is fast. However, when the constant subquery was optimized away, it was neither cached by the subquery cache, nor it was cached by the internal subquery caching. The latter was due to the fact that the subquery still appeared as correlated to the subselect_XYZ_engine::exec methods, and they re-executed the subquery on each call to Item_subselect::exec. Solution: The solution is to update the correlated status of the subquery after it has been optimized. This status consists of: - st_select_lex::is_correlated - Item_subselect::is_correlated - SELECT_LEX::uncacheable - SELECT_LEX_UNIT::uncacheable The status is updated by st_select_lex::update_correlated_cache(), and its caller st_select_lex::optimize_unflattened_subqueries. The solution relies on the fact that the optimizer already called st_select_lex::update_used_tables() for each subquery. This allows to efficiently update the correlated status of each subquery without walking the whole subquery tree. Notice that his patch is an improvement over MySQL 5.6 and older, where subqueries are not pre-optimized, and the above analysis is not possible.
2012-05-30 00:18:53 +03:00
2 SUBQUERY NULL NULL NULL NULL NULL NULL NULL no matching row in const table
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
select min(a1) from t1 where 7 in (select max(b1) from t2 group by b1);
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
min(a1)
Fixed LP bug #702301. The function matching_cond should take into account that there may be always false constant conjunctive conditions that has not been evaluated yet,for example, conjunctive conditions with non-correlated subqueries.
2011-07-20 16:09:28 -07:00
NULL
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @@optimizer_switch=@optimizer_switch_local_default;
set @@optimizer_switch='semijoin=off';
MWL#89: Cost-based choice between Materialization and IN->EXISTS transformation - Added more tests to the MWL#89 specific test, and made the test more modular. - Updated test files. - Fixed a memory leak. - More comments. mysql-test/r/subselect_mat.result: - Updated the test file to reflect the new optimizer switches related to materialized subquery execution. - Added one extra test to test all cases that expose BUG#40037 (this is an old bug from 5.x). - Updated the test result with correct results that expose BUG#40037. mysql-test/t/subselect_mat.test: - Updated the test file to reflect the new optimizer switches related to materialized subquery execution. - Added one extra test to test all cases that expose BUG#40037 (this is an old bug from 5.x). - Updated the test result with correct results that expose BUG#40037. sql/sql_select.cc: Fixed a memory leak reported by Valgrind.
2010-10-20 15:43:55 +03:00
explain select min(a1) from t1 where 7 in (select b1 from t2);
id select_type table type possible_keys key key_len ref rows Extra
Merged the fix for bug lp:944706, mdev-193
2012-06-19 15:06:45 +03:00
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL Impossible WHERE
Fix for bug lp:944706, task MDEV-193 The patch enables back constant subquery execution during query optimization after it was disabled during the development of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION). The main idea is that constant subqueries are allowed to be executed during optimization if their execution is not expensive. The approach is as follows: - Constant subqueries are recursively optimized in the beginning of JOIN::optimize of the outer query. This is done by the new method JOIN::optimize_constant_subqueries(). This is done so that the cost of executing these queries can be estimated. - Optimization of the outer query proceeds normally. During this phase the optimizer may request execution of non-expensive constant subqueries. Each place where the optimizer may potentially execute an expensive expression is guarded with the predicate Item::is_expensive(). - The implementation of Item_subselect::is_expensive has been extended to use the number of examined rows (estimated by the optimizer) as a way to determine whether the subquery is expensive or not. - The new system variable "expensive_subquery_limit" controls how many examined rows are considered to be not expensive. The default is 100. In addition, multiple changes were needed to make this solution work in the light of the changes made by MWL#89. These changes were needed to fix various crashes and wrong results, and legacy bugs discovered during development.
2012-05-17 13:46:05 +03:00
2 MATERIALIZED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
MWL#89: Cost-based choice between Materialization and IN->EXISTS transformation - Added more tests to the MWL#89 specific test, and made the test more modular. - Updated test files. - Fixed a memory leak. - More comments. mysql-test/r/subselect_mat.result: - Updated the test file to reflect the new optimizer switches related to materialized subquery execution. - Added one extra test to test all cases that expose BUG#40037 (this is an old bug from 5.x). - Updated the test result with correct results that expose BUG#40037. mysql-test/t/subselect_mat.test: - Updated the test file to reflect the new optimizer switches related to materialized subquery execution. - Added one extra test to test all cases that expose BUG#40037 (this is an old bug from 5.x). - Updated the test result with correct results that expose BUG#40037. sql/sql_select.cc: Fixed a memory leak reported by Valgrind.
2010-10-20 15:43:55 +03:00
select min(a1) from t1 where 7 in (select b1 from t2);
min(a1)
Fixed LP bug #702301. The function matching_cond should take into account that there may be always false constant conjunctive conditions that has not been evaluated yet,for example, conjunctive conditions with non-correlated subqueries.
2011-07-20 16:09:28 -07:00
NULL
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @@optimizer_switch=@optimizer_switch_local_default;
set @@optimizer_switch='materialization=off,in_to_exists=on';
Post-merge fix for tests - bad .result merge - make .test file do not switch off both materialization and IN->EXISTS as that leads to error now.
2011-05-29 00:51:26 +04:00
# with MariaDB and MWL#90, this particular case is solved:
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
explain select min(a1) from t1 where 7 in (select b1 from t2);
id select_type table type possible_keys key key_len ref rows Extra
Merged the fix for bug lp:944706, mdev-193
2012-06-19 15:06:45 +03:00
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL Impossible WHERE
Patch for mdev-287: CHEAP SQ: A query with subquery in SELECT list, EXISTS, inner joins takes hundreds times longer Analysis: The fix for lp:944706 introduces early subquery optimization. While a subquery is being optimized some of its predicates may be removed. In the test case, the EXISTS subquery is constant, and is evaluated to TRUE. As a result the whole OR is TRUE, and thus the correlated condition "b = alias1.b" is optimized away. The subquery becomes non-correlated. The subquery cache is designed to work only for correlated subqueries. If constant subquery optimization is disallowed, then the constant subquery is not evaluated, the subquery remains correlated, and its execution is cached. As a result execution is fast. However, when the constant subquery was optimized away, it was neither cached by the subquery cache, nor it was cached by the internal subquery caching. The latter was due to the fact that the subquery still appeared as correlated to the subselect_XYZ_engine::exec methods, and they re-executed the subquery on each call to Item_subselect::exec. Solution: The solution is to update the correlated status of the subquery after it has been optimized. This status consists of: - st_select_lex::is_correlated - Item_subselect::is_correlated - SELECT_LEX::uncacheable - SELECT_LEX_UNIT::uncacheable The status is updated by st_select_lex::update_correlated_cache(), and its caller st_select_lex::optimize_unflattened_subqueries. The solution relies on the fact that the optimizer already called st_select_lex::update_used_tables() for each subquery. This allows to efficiently update the correlated status of each subquery without walking the whole subquery tree. Notice that his patch is an improvement over MySQL 5.6 and older, where subqueries are not pre-optimized, and the above analysis is not possible.
2012-05-30 00:18:53 +03:00
2 SUBQUERY NULL NULL NULL NULL NULL NULL NULL no matching row in const table
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select min(a1) from t1 where 7 in (select b1 from t2);
min(a1)
Fixed LP bug #702301. The function matching_cond should take into account that there may be always false constant conjunctive conditions that has not been evaluated yet,for example, conjunctive conditions with non-correlated subqueries.
2011-07-20 16:09:28 -07:00
NULL
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - First code (needs cleanup).
2010-04-06 00:16:45 +04:00
# but when we go around MWL#90 code, the problem still shows up:
explain select min(a1) from t1 where 7 in (select b1 from t2) or 2> 4;
id select_type table type possible_keys key key_len ref rows Extra
Merged the fix for bug lp:944706, mdev-193
2012-06-19 15:06:45 +03:00
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL Impossible WHERE
Patch for mdev-287: CHEAP SQ: A query with subquery in SELECT list, EXISTS, inner joins takes hundreds times longer Analysis: The fix for lp:944706 introduces early subquery optimization. While a subquery is being optimized some of its predicates may be removed. In the test case, the EXISTS subquery is constant, and is evaluated to TRUE. As a result the whole OR is TRUE, and thus the correlated condition "b = alias1.b" is optimized away. The subquery becomes non-correlated. The subquery cache is designed to work only for correlated subqueries. If constant subquery optimization is disallowed, then the constant subquery is not evaluated, the subquery remains correlated, and its execution is cached. As a result execution is fast. However, when the constant subquery was optimized away, it was neither cached by the subquery cache, nor it was cached by the internal subquery caching. The latter was due to the fact that the subquery still appeared as correlated to the subselect_XYZ_engine::exec methods, and they re-executed the subquery on each call to Item_subselect::exec. Solution: The solution is to update the correlated status of the subquery after it has been optimized. This status consists of: - st_select_lex::is_correlated - Item_subselect::is_correlated - SELECT_LEX::uncacheable - SELECT_LEX_UNIT::uncacheable The status is updated by st_select_lex::update_correlated_cache(), and its caller st_select_lex::optimize_unflattened_subqueries. The solution relies on the fact that the optimizer already called st_select_lex::update_used_tables() for each subquery. This allows to efficiently update the correlated status of each subquery without walking the whole subquery tree. Notice that his patch is an improvement over MySQL 5.6 and older, where subqueries are not pre-optimized, and the above analysis is not possible.
2012-05-30 00:18:53 +03:00
2 SUBQUERY NULL NULL NULL NULL NULL NULL NULL no matching row in const table
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - First code (needs cleanup).
2010-04-06 00:16:45 +04:00
select min(a1) from t1 where 7 in (select b1 from t2) or 2> 4;
min(a1)
Fixed LP bug #702301. The function matching_cond should take into account that there may be always false constant conjunctive conditions that has not been evaluated yet,for example, conjunctive conditions with non-correlated subqueries.
2011-07-20 16:09:28 -07:00
NULL
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - Code cleanu. - Make MWL#90 code require @@optimizer_switch='semijoin=on' - Update test results with the above - Fork subselect_mat.test - we want to check both semi-join materialization, which now has broader scope and non-semijoin materialization.
2010-05-25 10:32:15 +04:00
set @@optimizer_switch= @save_optimizer_switch;
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
drop table t1,t2;
create table t1 (a char(2), b varchar(10));
insert into t1 values ('a', 'aaa');
insert into t1 values ('aa', 'aaaa');
explain select a,b from t1 where b in (select a from t1);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 2 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t1 ALL NULL NULL NULL NULL 2
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
select a,b from t1 where b in (select a from t1);
a b
prepare st1 from "select a,b from t1 where b in (select a from t1)";
execute st1;
a b
execute st1;
a b
drop table t1;
Bug lp:781508: Take relevant test cases from MySQL 5.6 feature preview trees Identified all test cases in the MySQL file subquery_mat.inc that are not present in MariaDB. In total found 8 test cases for the following MySQL bugs: * BUG#49630 - not a bug in MariaDB, added test case * BUG#52538 - not a bug in MariaDB, added test case (checked with VG) * BUG#53103 - not a bug in MariaDB, added test case * BUG#54511 - not a bug in MariaDB, added test case * BUG#56367 - not a bug in MariaDB, added test case * BUG#59833 - not a bug in MariaDB, added test case * BUG#11852644 - not a bug in MariaDB, added test case * BUG#12668294 - not a bug in MariaDB, added test case All of these MySQL bugs are not present in MariaDB 5.3. The comparison was based on the following version of mysql-trunk: revno: 3350 [merge] committer: Marko Mäkelä <marko.makela@oracle.com> branch nick: mysql-trunk timestamp: Mon 2011-08-08 12:42:09 +0300 message: Merge mysql-5.5 to mysql-trunk.
2011-08-09 18:34:26 +03:00
#
# BUG#49630: Segfault in select_describe() with double
# nested subquery and materialization
#
CREATE TABLE t1 (t1i int);
CREATE TABLE t2 (t2i int);
CREATE TABLE t3 (t3i int);
CREATE TABLE t4 (t4i int);
INSERT INTO t1 VALUES (1);
INSERT INTO t2 VALUES (1),(2);
INSERT INTO t3 VALUES (1),(2);
INSERT INTO t4 VALUES (1),(2);
EXPLAIN
SELECT t1i
FROM t1 JOIN t4 ON t1i=t4i
WHERE (t1i) IN (
SELECT t2i
FROM t2
WHERE (t2i) IN (
Backport of WL#5953 from MySQL 5.6 The patch differs from the original MySQL patch as follows: - All test case differences have been reviewed one by one, and care has been taken to restore the original plan so that each test case executes the code path it was designed for. - A bug was found and fixed in MariaDB 5.3 in Item_allany_subselect::cleanup(). - ORDER BY is not removed because we are unsure of all effects, and it would prevent enabling ORDER BY ... LIMIT subqueries. - ref_pointer_array.m_size is not adjusted because we don't do array bounds checking, and because it looks risky. Original comment by Jorgen Loland: ------------------------------------------------------------- WL#5953 - Optimize away useless subquery clauses For IN/ALL/ANY/SOME/EXISTS subqueries, the following clauses are meaningless: * ORDER BY (since we don't support LIMIT in these subqueries) * DISTINCT * GROUP BY if there is no HAVING clause and no aggregate functions This WL detects and optimizes away these useless parts of the query during JOIN::prepare()
2011-12-19 23:05:44 +02:00
SELECT max(t3i)
Bug lp:781508: Take relevant test cases from MySQL 5.6 feature preview trees Identified all test cases in the MySQL file subquery_mat.inc that are not present in MariaDB. In total found 8 test cases for the following MySQL bugs: * BUG#49630 - not a bug in MariaDB, added test case * BUG#52538 - not a bug in MariaDB, added test case (checked with VG) * BUG#53103 - not a bug in MariaDB, added test case * BUG#54511 - not a bug in MariaDB, added test case * BUG#56367 - not a bug in MariaDB, added test case * BUG#59833 - not a bug in MariaDB, added test case * BUG#11852644 - not a bug in MariaDB, added test case * BUG#12668294 - not a bug in MariaDB, added test case All of these MySQL bugs are not present in MariaDB 5.3. The comparison was based on the following version of mysql-trunk: revno: 3350 [merge] committer: Marko Mäkelä <marko.makela@oracle.com> branch nick: mysql-trunk timestamp: Mon 2011-08-08 12:42:09 +0300 message: Merge mysql-5.5 to mysql-trunk.
2011-08-09 18:34:26 +03:00
FROM t3
GROUP BY t3i
)
);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 system NULL NULL NULL NULL 1
1 PRIMARY t4 ALL NULL NULL NULL NULL 2 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 2 Using where
3 MATERIALIZED t3 ALL NULL NULL NULL NULL 2 Using temporary
Bug lp:781508: Take relevant test cases from MySQL 5.6 feature preview trees Identified all test cases in the MySQL file subquery_mat.inc that are not present in MariaDB. In total found 8 test cases for the following MySQL bugs: * BUG#49630 - not a bug in MariaDB, added test case * BUG#52538 - not a bug in MariaDB, added test case (checked with VG) * BUG#53103 - not a bug in MariaDB, added test case * BUG#54511 - not a bug in MariaDB, added test case * BUG#56367 - not a bug in MariaDB, added test case * BUG#59833 - not a bug in MariaDB, added test case * BUG#11852644 - not a bug in MariaDB, added test case * BUG#12668294 - not a bug in MariaDB, added test case All of these MySQL bugs are not present in MariaDB 5.3. The comparison was based on the following version of mysql-trunk: revno: 3350 [merge] committer: Marko Mäkelä <marko.makela@oracle.com> branch nick: mysql-trunk timestamp: Mon 2011-08-08 12:42:09 +0300 message: Merge mysql-5.5 to mysql-trunk.
2011-08-09 18:34:26 +03:00
DROP TABLE t1,t2,t3,t4;
CREATE TABLE t1 (
pk INTEGER AUTO_INCREMENT,
col_int_nokey INTEGER,
col_int_key INTEGER,
col_varchar_key VARCHAR(1),
PRIMARY KEY (pk),
KEY (col_int_key),
KEY (col_varchar_key, col_int_key)
)
;
INSERT INTO t1 (
col_int_key, col_int_nokey, col_varchar_key
)
VALUES
(2, NULL, 'w'),
(9, 7, 'm'),
(3, 9, 'm'),
(9, 7, 'k'),
(NULL, 4, 'r'),
(9, 2, 't'),
(3, 6, 'j'),
(8, 8, 'u'),
(8, NULL, 'h'),
(53, 5, 'o'),
(0, NULL, NULL),
(5, 6, 'k'),
(166, 188, 'e'),
(3, 2, 'n'),
(0, 1, 't'),
(1, 1, 'c'),
(9, 0, 'm'),
(5, 9, 'y'),
(6, NULL, 'f'),
(2, 4, 'd')
;
SELECT table2.col_varchar_key AS field1,
table2.col_int_nokey AS field2
FROM ( t1 AS table1 LEFT OUTER JOIN t1 AS table2
ON (table2.col_varchar_key = table1.col_varchar_key ) )
WHERE table1.pk = 6
HAVING ( field2 ) IN
( SELECT SUBQUERY2_t2.col_int_nokey AS SUBQUERY2_field2
FROM ( t1 AS SUBQUERY2_t1 JOIN t1 AS SUBQUERY2_t2
ON (SUBQUERY2_t2.col_varchar_key = SUBQUERY2_t1.col_varchar_key ) ) )
ORDER BY field2
;
field1 field2
t 1
t 2
drop table t1;
#
# BUG#53103: MTR test ps crashes in optimize_cond()
# when running with --debug
#
CREATE TABLE t1(track varchar(15));
INSERT INTO t1 VALUES ('CAD'), ('CAD');
PREPARE STMT FROM
"SELECT 1 FROM t1
WHERE
track IN (SELECT track FROM t1
GROUP BY track
HAVING track>='CAD')";
EXECUTE STMT ;
1
1
1
EXECUTE STMT ;
1
1
1
DEALLOCATE PREPARE STMT;
DROP TABLE t1;
# End of BUG#53103
#
# BUG#54511 - Assertion failed: cache != 0L in file
# sql_select.cc::sub_select_cache on HAVING
#
CREATE TABLE t1 (i int(11));
CREATE TABLE t2 (c char(1));
CREATE TABLE t3 (c char(1));
INSERT INTO t1 VALUES (1), (2);
INSERT INTO t2 VALUES ('a'), ('b');
INSERT INTO t3 VALUES ('x'), ('y');
SELECT COUNT( i ),i
FROM t1
HAVING ('c')
IN (SELECT t2.c FROM (t2 JOIN t3));
COUNT( i ) i
DROP TABLE t1,t2,t3;
# End BUG#54511
#
# BUG#56367 - Assertion exec_method != EXEC_MATERIALIZATION...
# on subquery in FROM
#
CREATE TABLE t1 (a INTEGER);
CREATE TABLE t2 (b INTEGER);
INSERT INTO t2 VALUES (1);
Set new default values for the optimizer switch flags 'derived_merge' and 'derived_with_keys'. Now they are set on by default.
2011-11-26 14:23:00 -08:00
set @tmp_optimizer_switch=@@optimizer_switch;
set optimizer_switch='derived_merge=off,derived_with_keys=off';
Bug lp:781508: Take relevant test cases from MySQL 5.6 feature preview trees Identified all test cases in the MySQL file subquery_mat.inc that are not present in MariaDB. In total found 8 test cases for the following MySQL bugs: * BUG#49630 - not a bug in MariaDB, added test case * BUG#52538 - not a bug in MariaDB, added test case (checked with VG) * BUG#53103 - not a bug in MariaDB, added test case * BUG#54511 - not a bug in MariaDB, added test case * BUG#56367 - not a bug in MariaDB, added test case * BUG#59833 - not a bug in MariaDB, added test case * BUG#11852644 - not a bug in MariaDB, added test case * BUG#12668294 - not a bug in MariaDB, added test case All of these MySQL bugs are not present in MariaDB 5.3. The comparison was based on the following version of mysql-trunk: revno: 3350 [merge] committer: Marko Mäkelä <marko.makela@oracle.com> branch nick: mysql-trunk timestamp: Mon 2011-08-08 12:42:09 +0300 message: Merge mysql-5.5 to mysql-trunk.
2011-08-09 18:34:26 +03:00
explain SELECT a FROM (
SELECT t1.* FROM t1 LEFT JOIN t2 ON t1.a > 3 OR t2.b IN (SELECT a FROM t1)
) table1;
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <derived2> ALL NULL NULL NULL NULL 2
2 DERIVED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
3 MATERIALIZED NULL NULL NULL NULL NULL NULL NULL no matching row in const table
Bug lp:781508: Take relevant test cases from MySQL 5.6 feature preview trees Identified all test cases in the MySQL file subquery_mat.inc that are not present in MariaDB. In total found 8 test cases for the following MySQL bugs: * BUG#49630 - not a bug in MariaDB, added test case * BUG#52538 - not a bug in MariaDB, added test case (checked with VG) * BUG#53103 - not a bug in MariaDB, added test case * BUG#54511 - not a bug in MariaDB, added test case * BUG#56367 - not a bug in MariaDB, added test case * BUG#59833 - not a bug in MariaDB, added test case * BUG#11852644 - not a bug in MariaDB, added test case * BUG#12668294 - not a bug in MariaDB, added test case All of these MySQL bugs are not present in MariaDB 5.3. The comparison was based on the following version of mysql-trunk: revno: 3350 [merge] committer: Marko Mäkelä <marko.makela@oracle.com> branch nick: mysql-trunk timestamp: Mon 2011-08-08 12:42:09 +0300 message: Merge mysql-5.5 to mysql-trunk.
2011-08-09 18:34:26 +03:00
SELECT a FROM (
SELECT t1.* FROM t1 LEFT JOIN t2 ON t1.a > 3 OR t2.b IN (SELECT a FROM t1)
) table1;
a
Set new default values for the optimizer switch flags 'derived_merge' and 'derived_with_keys'. Now they are set on by default.
2011-11-26 14:23:00 -08:00
set optimizer_switch=@tmp_optimizer_switch;
Bug lp:781508: Take relevant test cases from MySQL 5.6 feature preview trees Identified all test cases in the MySQL file subquery_mat.inc that are not present in MariaDB. In total found 8 test cases for the following MySQL bugs: * BUG#49630 - not a bug in MariaDB, added test case * BUG#52538 - not a bug in MariaDB, added test case (checked with VG) * BUG#53103 - not a bug in MariaDB, added test case * BUG#54511 - not a bug in MariaDB, added test case * BUG#56367 - not a bug in MariaDB, added test case * BUG#59833 - not a bug in MariaDB, added test case * BUG#11852644 - not a bug in MariaDB, added test case * BUG#12668294 - not a bug in MariaDB, added test case All of these MySQL bugs are not present in MariaDB 5.3. The comparison was based on the following version of mysql-trunk: revno: 3350 [merge] committer: Marko Mäkelä <marko.makela@oracle.com> branch nick: mysql-trunk timestamp: Mon 2011-08-08 12:42:09 +0300 message: Merge mysql-5.5 to mysql-trunk.
2011-08-09 18:34:26 +03:00
DROP TABLE t1, t2;
# End BUG#56367
#
# Bug#59833 - materialization=on/off leads to different result set
# when using IN
#
CREATE TABLE t1 (
pk int NOT NULL,
f1 int DEFAULT NULL,
PRIMARY KEY (pk)
) ENGINE=MyISAM;
CREATE TABLE t2 (
pk int NOT NULL,
f1 int DEFAULT NULL,
PRIMARY KEY (pk)
) ENGINE=MyISAM;
INSERT INTO t1 VALUES (10,0);
INSERT INTO t2 VALUES (10,0),(11,0);
explain SELECT * FROM t1 JOIN t2 USING (f1)
WHERE t1.f1 IN (SELECT t1.pk FROM t1 ORDER BY t1.f1);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 system NULL NULL NULL NULL 1
1 PRIMARY t2 ALL NULL NULL NULL NULL 2 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t1 system NULL NULL NULL NULL 1
Bug lp:781508: Take relevant test cases from MySQL 5.6 feature preview trees Identified all test cases in the MySQL file subquery_mat.inc that are not present in MariaDB. In total found 8 test cases for the following MySQL bugs: * BUG#49630 - not a bug in MariaDB, added test case * BUG#52538 - not a bug in MariaDB, added test case (checked with VG) * BUG#53103 - not a bug in MariaDB, added test case * BUG#54511 - not a bug in MariaDB, added test case * BUG#56367 - not a bug in MariaDB, added test case * BUG#59833 - not a bug in MariaDB, added test case * BUG#11852644 - not a bug in MariaDB, added test case * BUG#12668294 - not a bug in MariaDB, added test case All of these MySQL bugs are not present in MariaDB 5.3. The comparison was based on the following version of mysql-trunk: revno: 3350 [merge] committer: Marko Mäkelä <marko.makela@oracle.com> branch nick: mysql-trunk timestamp: Mon 2011-08-08 12:42:09 +0300 message: Merge mysql-5.5 to mysql-trunk.
2011-08-09 18:34:26 +03:00
SELECT * FROM t1 JOIN t2 USING (f1)
WHERE t1.f1 IN (SELECT t1.pk FROM t1 ORDER BY t1.f1);
f1 pk pk
DROP TABLE t1, t2;
# End Bug#59833
#
# Bug#11852644 - CRASH IN ITEM_REF::SAVE_IN_FIELD ON SELECT DISTINCT
#
CREATE TABLE t1 (
col_varchar_key varchar(1) DEFAULT NULL,
col_varchar_nokey varchar(1) DEFAULT NULL,
KEY col_varchar_key (col_varchar_key))
;
INSERT INTO t1 VALUES
('v','v'),('r','r');
CREATE TABLE t2 (
col_varchar_key varchar(1) DEFAULT NULL,
col_varchar_nokey varchar(1) DEFAULT NULL,
KEY col_varchar_key(col_varchar_key))
;
INSERT INTO t2 VALUES
('r','r'),('c','c');
CREATE VIEW v3 AS SELECT * FROM t2;
SELECT DISTINCT alias2.col_varchar_key
FROM t1 AS alias1 JOIN v3 AS alias2
ON alias2.col_varchar_key = alias1.col_varchar_key
HAVING col_varchar_key IN (SELECT col_varchar_nokey FROM t2)
;
col_varchar_key
r
DROP TABLE t1, t2;
DROP VIEW v3;
# End Bug#11852644
# Bug#12668294 - GROUP BY ON EMPTY RESULT GIVES EMPTY ROW
# INSTEAD OF NULL WHEN MATERIALIZATION ON
CREATE TABLE t1 (col_int_nokey INT) ENGINE=MEMORY;
CREATE TABLE t2 (col_int_nokey INT) ENGINE=MEMORY;
INSERT INTO t2 VALUES (8),(7);
CREATE TABLE t3 (col_int_nokey INT) ENGINE=MEMORY;
INSERT INTO t3 VALUES (7);
SELECT MIN(t3.col_int_nokey),t1.col_int_nokey AS field3
FROM t3
LEFT JOIN t1
ON t1.col_int_nokey
WHERE (194, 200) IN (
SELECT SQ4_alias1.col_int_nokey,
SQ4_alias2.col_int_nokey
FROM t2 AS SQ4_alias1
JOIN
t2 AS SQ4_alias2
ON SQ4_alias2.col_int_nokey = 5
)
GROUP BY field3 ;
MIN(t3.col_int_nokey) field3
DROP TABLE t1;
DROP TABLE t2;
DROP TABLE t3;
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
CREATE TABLE t1 (f1 INT, f2 DECIMAL(5,3)) ENGINE=MyISAM;
INSERT INTO t1 (f1, f2) VALUES (1, 1.789);
INSERT INTO t1 (f1, f2) VALUES (13, 1.454);
INSERT INTO t1 (f1, f2) VALUES (10, 1.668);
CREATE TABLE t2 LIKE t1;
INSERT INTO t2 VALUES (1, 1.789);
INSERT INTO t2 VALUES (13, 1.454);
Post-merge fix for tests - bad .result merge - make .test file do not switch off both materialization and IN->EXISTS as that leads to error now.
2011-05-29 00:51:26 +04:00
set @save_optimizer_switch=@@optimizer_switch;
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @@optimizer_switch=@optimizer_switch_local_default;
SET @@optimizer_switch='semijoin=on,materialization=on';
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
EXPLAIN SELECT COUNT(*) FROM t1 WHERE (f1,f2) IN (SELECT f1,f2 FROM t2);
id select_type table type possible_keys key key_len ref rows Extra
MWL#90, code cleanup - Unify EXPLAIN printout for <subqueryN> tables with regular tables - Update test results for <subqueryN> tables: s/unique_key/distinct_key/g s/1.0/100.0/ for "filtered" column
2010-06-09 18:43:52 +04:00
1 PRIMARY <subquery2> ALL distinct_key NULL NULL NULL 2
MWL#128: Added into EXPLAIN output info about types of the used join buffers and about the employed join algorithms. Refactored constructors of the JOIN_CACHE* classes.
2010-10-18 13:33:05 -07:00
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 Using where; Using join buffer (flat, BNL join)
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 2
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
SELECT COUNT(*) FROM t1 WHERE (f1,f2) IN (SELECT f1,f2 FROM t2);
COUNT(*)
2
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - Code cleanu. - Make MWL#90 code require @@optimizer_switch='semijoin=on' - Update test results with the above - Fork subselect_mat.test - we want to check both semi-join materialization, which now has broader scope and non-semijoin materialization.
2010-05-25 10:32:15 +04:00
set @@optimizer_switch= @save_optimizer_switch;
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
DROP TABLE t1, t2;
CREATE TABLE t1 (
pk int,
a varchar(1),
b varchar(4),
c varchar(4),
d varchar(4),
PRIMARY KEY (pk)
);
INSERT INTO t1 VALUES (1,'o','ffff','ffff','ffoo'),(2,'f','ffff','ffff','ffff');
CREATE TABLE t2 LIKE t1;
INSERT INTO t2 VALUES (1,'i','iiii','iiii','iiii'),(2,'f','ffff','ffff','ffff');
Post-merge fix for tests - bad .result merge - make .test file do not switch off both materialization and IN->EXISTS as that leads to error now.
2011-05-29 00:51:26 +04:00
set @save_optimizer_switch=@@optimizer_switch;
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @@optimizer_switch=@optimizer_switch_local_default;
SET @@optimizer_switch='semijoin=on,materialization=on';
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
EXPLAIN SELECT pk FROM t1 WHERE (a) IN (SELECT a FROM t2 WHERE pk > 0);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 2
Fixed LP bug #939009. The result of materialization of the right part of an IN subquery predicate is placed into a temporary table. Each row of the materialized table is distinct. A unique key over all fields of the temporary table is defined and created. It allows to perform key look-ups into the table. The table created for a materialized subquery can be accessed by key as any other table. The function best_access-path search for the best access to join a table to a given partial join. With some where conditions this function considers a possibility of a ref_or_null access. If such access employs the unique key on the temporary table then when estimating the cost this access the function tries to use the array rec_per_key. Yet, such array is not built for this unique key. This causes a crash of the server. Rows returned by the subquery that contain nulls don't have to be placed into temporary table, as they cannot be match any row produced by the left part of the subquery predicate. So all fields of the temporary table can be defined as non-nullable. In this case any ref_or_null access to the temporary table does not make any sense and it does not make sense to estimate such an access. The fix makes sure that the temporary table for a materialized IN subquery is defined with columns that are all non-nullable. The also ensures that any row with nulls returned by the subquery is not placed into the temporary table.
2012-02-24 16:50:22 -08:00
1 PRIMARY <subquery2> eq_ref distinct_key distinct_key 4 func 1
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 range PRIMARY PRIMARY 4 NULL 2 Using index condition; Rowid-ordered scan
Backport of subquery optimizations to 5.3. There are still test failures because of: - Wrong query results in outer join + semi join - EXPLAIN output differences
2010-01-17 17:51:10 +03:00
SELECT pk FROM t1 WHERE (a) IN (SELECT a FROM t2 WHERE pk > 0);
pk
2
SELECT pk FROM t1 WHERE (b,c,d) IN (SELECT b,c,d FROM t2 WHERE pk > 0);
pk
2
DROP TABLE t1, t2;
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - Code cleanu. - Make MWL#90 code require @@optimizer_switch='semijoin=on' - Update test results with the above - Fork subselect_mat.test - we want to check both semi-join materialization, which now has broader scope and non-semijoin materialization.
2010-05-25 10:32:15 +04:00
set optimizer_switch=@save_optimizer_switch;
BUG#45174: XOR in subqueries produces differing results in 5.1 and 5.4 BUG#50019: Wrong result for IN-subquery with materialization - Fix equality substitution in presense of semi-join materialization, lookup and scan variants (started off from fix by Evgen Potemkin, then modified it to work in all cases)
2010-03-13 23:04:52 +03:00
#
# BUG#50019: Wrong result for IN-subquery with materialization
#
create table t1(i int);
insert into t1 values (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);
create table t2(i int);
insert into t2 values (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);
create table t3(i int);
insert into t3 values (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);
select * from t1 where t1.i in (select t2.i from t2 join t3 where t2.i + t3.i = 5);
i
1
2
3
4
set @save_optimizer_switch=@@optimizer_switch;
MWL#89: Cost-based choice between Materialization and IN->EXISTS transformation - Added more tests to the MWL#89 specific test, and made the test more modular. - Updated test files. - Fixed a memory leak. - More comments. mysql-test/r/subselect_mat.result: - Updated the test file to reflect the new optimizer switches related to materialized subquery execution. - Added one extra test to test all cases that expose BUG#40037 (this is an old bug from 5.x). - Updated the test result with correct results that expose BUG#40037. mysql-test/t/subselect_mat.test: - Updated the test file to reflect the new optimizer switches related to materialized subquery execution. - Added one extra test to test all cases that expose BUG#40037 (this is an old bug from 5.x). - Updated the test result with correct results that expose BUG#40037. sql/sql_select.cc: Fixed a memory leak reported by Valgrind.
2010-10-20 15:43:55 +03:00
set session optimizer_switch='materialization=off,in_to_exists=on';
BUG#45174: XOR in subqueries produces differing results in 5.1 and 5.4 BUG#50019: Wrong result for IN-subquery with materialization - Fix equality substitution in presense of semi-join materialization, lookup and scan variants (started off from fix by Evgen Potemkin, then modified it to work in all cases)
2010-03-13 23:04:52 +03:00
select * from t1 where t1.i in (select t2.i from t2 join t3 where t2.i + t3.i = 5);
i
1
2
3
4
set session optimizer_switch=@save_optimizer_switch;
drop table t1, t2, t3;
Fixed a problem where the temp table of a materialized subquery was not cleaned up between PS re-executions. The reason was two-fold: - a merge with mysql-6.0 missed select_union::cleanup() that should have cleaned up the temp table, and - the subclass of select_union used by materialization didn't call the base class cleanup() method.
2010-07-16 14:02:15 +03:00
create table t0 (a int);
insert into t0 values (0),(1),(2);
create table t1 (a int);
insert into t1 values (0),(1),(2);
explain select a, a in (select a from t1) from t0;
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t0 ALL NULL NULL NULL NULL 3
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t1 ALL NULL NULL NULL NULL 3
Fixed a problem where the temp table of a materialized subquery was not cleaned up between PS re-executions. The reason was two-fold: - a merge with mysql-6.0 missed select_union::cleanup() that should have cleaned up the temp table, and - the subclass of select_union used by materialization didn't call the base class cleanup() method.
2010-07-16 14:02:15 +03:00
select a, a in (select a from t1) from t0;
a a in (select a from t1)
0 1
1 1
2 1
prepare s from 'select a, a in (select a from t1) from t0';
execute s;
a a in (select a from t1)
0 1
1 1
2 1
update t1 set a=123;
execute s;
a a in (select a from t1)
0 0
1 0
2 0
drop table t0, t1;
MWL#90: Subqueries: Inside-out execution for non-semijoin materialized subqueries that are AND-parts of the WHERE - Code cleanu. - Make MWL#90 code require @@optimizer_switch='semijoin=on' - Update test results with the above - Fork subselect_mat.test - we want to check both semi-join materialization, which now has broader scope and non-semijoin materialization.
2010-05-25 10:32:15 +04:00
set optimizer_switch='firstmatch=on';
MWL#90: address review feedback: more test coverage - Forgot to add .result file
2011-04-05 11:16:28 +04:00
#
# MWL#90, review feedback: check what happens when the subquery
# looks like candidate for MWL#90 checking at the first glance
# but then subselect_hash_sj_engine::init_permanent() discovers
# that it's not possible to perform duplicate removal for the
# selected datatypes, and so materialization isn't applicable after
# all.
#
set @blob_len = 1024;
set @suffix_len = @blob_len - @prefix_len;
create table t1_1024 (a1 blob(1024), a2 blob(1024));
create table t2_1024 (b1 blob(1024), b2 blob(1024));
insert into t1_1024 values
(concat('1 - 00', repeat('x', @suffix_len)), concat('2 - 00', repeat('x', @suffix_len)));
insert into t1_1024 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t1_1024 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t2_1024 values
(concat('1 - 01', repeat('x', @suffix_len)), concat('2 - 01', repeat('x', @suffix_len)));
insert into t2_1024 values
(concat('1 - 02', repeat('x', @suffix_len)), concat('2 - 02', repeat('x', @suffix_len)));
insert into t2_1024 values
(concat('1 - 03', repeat('x', @suffix_len)), concat('2 - 03', repeat('x', @suffix_len)));
explain select left(a1,7), left(a2,7) from t1_1024 where (a1,3) in (select substring(b1,1,1024), count(*) from t2_1024 where b1 > '0');
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1_1024 ALL NULL NULL NULL NULL 3 Using where
2 DEPENDENT SUBQUERY t2_1024 ALL NULL NULL NULL NULL 3 Using where
select left(a1,7), left(a2,7) from t1_1024 where (a1,3) in (select substring(b1,1,1024), count(*) from t2_1024 where b1 > '0');
left(a1,7) left(a2,7)
1 - 01x 2 - 01x
drop table t1_1024, t2_1024;
BUG##836491: Crash in Item_field::Item_field from add_ref_to_table_cond() with semijoin+materialization - Let create_tmp_table set KEY_PART_INFO::fieldnr. It is needed in add_ref_to_table_cond(), and possibly other places.
2011-08-29 21:54:16 +04:00
#
# BUG##836491: Crash in Item_field::Item_field from add_ref_to_table_cond() with semijoin+materialization
#
CREATE TABLE t1 (c int, d varchar(1), KEY(d)) ;
INSERT INTO t1 VALUES (2,'x'),(2,'x'),(2,'j'),(2,'c');
CREATE TABLE t2 (a int, d varchar(1)) ;
INSERT INTO t2 VALUES (1,'x');
CREATE TABLE t3 (d varchar(1)) ;
INSERT INTO t3 VALUES ('x'),('x'),('j'),('c');
SELECT t2.a, t1.c
FROM t1, t2
WHERE t2.d IN ( SELECT d FROM t3 )
AND t1.d = t2.d
GROUP BY 1 , 2;
a c
1 2
drop table t1,t2,t3;
BUG#836523: Crash in JOIN::get_partial_cost_and_fanout with semijoin+materialization - Make JOIN::get_partial_cost_and_fanout() be able to handle join plans with semi-join-materialization nests.
2011-09-02 22:43:35 +04:00
#
# BUG#836523: Crash in JOIN::get_partial_cost_and_fanout with semijoin+materialization
#
CREATE TABLE t1 (a varchar(1));
INSERT INTO t1 VALUES ('a'),('a');
CREATE TABLE t2 (a varchar(1));
CREATE TABLE t3 (a int);
INSERT INTO t3 VALUES (1),(2);
CREATE TABLE t4 (a varchar(1));
INSERT INTO t4 VALUES ('a'),('a');
SELECT t1.a
FROM t1
WHERE t1.a IN (
SELECT t2.a
FROM t2, t3
)
HAVING a IN (
SELECT a
FROM t4
);
a
DROP TABLE t1, t2, t3, t4;
BUG#836507: Crash in setup_sj_materialization_part1() with semijoin+materialization - setup_sj_materialization() code failed to take into account that it can be that the first [in join order ordering] table inside semi-join-materialization nest is also an inner table wrt an outer join (that is embedded in the semi-join). This can happen when all of the tables that are inside the semi-join but not inside the outer join are constant. - Made a trivial to not assume that table's embedding join nest is the semi-join nest: instead, walk up the outer join nests until we reach the semi-join nest.
2011-09-02 23:44:28 +04:00
#
# BUG#836507: Crash in setup_sj_materialization_part1() with semijoin+materialization
#
CREATE TABLE t1 (a int) ;
INSERT IGNORE INTO t1 VALUES (1),(1);
CREATE TABLE t2 (a int);
INSERT INTO t2 VALUES (1);
CREATE TABLE t3 (a int);
CREATE TABLE t4 (a int);
INSERT INTO t4 VALUES (2),(2);
CREATE TABLE t5 (a int);
INSERT INTO t5 VALUES (1);
SELECT * FROM t1
WHERE (a) IN (
SELECT t5.a
FROM (
t2
LEFT JOIN ( t3 , t4 )
ON 1 = 1
)
JOIN t5
);
a
1
1
DROP TABLE t1,t2,t3,t4,t5;
BUG#836532: Crash in Item_equal_fields_iterator::get_curr_field with semijoin+materialization - Item_in_subselect::inject_in_to_exists_cond() should not call ((Item_cond*)join->conds)->argument_list()->concat(join->cond_equal->current_level) as that makes two lists share their tail, and the cond_equal list will end up containing non-Item_equal objects when substitute_for_best_equal_field() walks through join->conds and replaces all Item_equal objects with Item_func_eq objects. - So, instead of using List::concat(), manually copy entries from one list to another.
2011-09-04 16:35:37 +04:00
#
# BUG#836532: Crash in Item_equal_fields_iterator::get_curr_field with semijoin+materialization
#
CREATE TABLE t2 (a int);
INSERT INTO t2 VALUES ('a'),('a');
Warnings:
Warning 1366 Incorrect integer value: 'a' for column 'a' at row 1
Warning 1366 Incorrect integer value: 'a' for column 'a' at row 2
CREATE TABLE t4 (a varchar(1));
INSERT INTO t4 VALUES ('m'),('o');
CREATE TABLE t3 (a varchar(1) , b varchar(1) ) ;
INSERT INTO t3 VALUES ('b','b');
CREATE TABLE t5 (a varchar(1), KEY (a)) ;
INSERT INTO t5 VALUES ('d'),('e');
SELECT *
FROM t2
WHERE t2.a = ALL (
SELECT t4.a
FROM t4
WHERE t4.a IN (
SELECT t3.a
FROM t3 , t5
WHERE ( t5.a = t3.b )
)
);
a
0
0
DROP TABLE t2,t3,t4,t5;
BUG#860300: Second crash with get_fanout_with_deps() with semijoin + materialization - Make get_post_group_estimate() take into account semi-join materialization nests.
2011-09-28 12:58:01 +04:00
#
# BUG#860300: Second crash with get_fanout_with_deps() with semijoin + materialization
#
set @tmp_860300=@@optimizer_switch;
set optimizer_switch='semijoin=on,materialization=on,loosescan=off,firstmatch=off';
CREATE TABLE t1 (f2 int);
INSERT INTO t1 VALUES (9),(6);
CREATE TABLE t3 (f4 int);
CREATE TABLE t4 (f6 varchar(1));
SELECT *
FROM t3
WHERE 'h' IN (SELECT f6
FROM t4
WHERE 5 IN (SELECT f2 FROM t1)
GROUP BY t4.f6);
f4
DROP TABLE t1,t3,t4;
set optimizer_switch=@tmp_860300;
BUG#860535: Assertion `keypart_map' failed in mi_rkey with semijoin - are_tables_local() failed to recognize the fact that OUTER_REF_TABLE_BIT is ok for SJ-Materialization. This caused zero-length ref access to be constructed, which led to an assert.
2011-09-29 17:03:12 +04:00
#
# BUG#860535: Assertion `keypart_map' failed in mi_rkey with semijoin
#
set @tmp_860535=@@optimizer_switch;
set optimizer_switch='semijoin=on,materialization=on,loosescan=off,firstmatch=off';
CREATE TABLE t1 (f3 int) ;
INSERT INTO t1 VALUES (1),(7);
CREATE TABLE t2 (f3 int , f5 varchar(1), KEY (f3)) ;
INSERT INTO t2 VALUES (7,'b');
CREATE TABLE t3 (f3 int , f4 varchar(1) , KEY(f3), KEY (f4,f3)) ;
INSERT INTO t3 VALUES (1,'t'),(7,'g');
CREATE TABLE t4
SELECT f3
FROM t1 WHERE ( f3 ) NOT IN (
SELECT f3
FROM t2
WHERE f5 IN (
SELECT f4
FROM t3
WHERE t3.f3 < 3
)
);
SELECT * FROM t4;
f3
1
7
DROP TABLE t1, t2, t3, t4;
set optimizer_switch=@tmp_860535;
BUG#860553: Crash in create_ref_for_key with semijoin + materialization - The problem was that JOIN::save/restore_query_plan() did not save/restore parts of the query plan that are located inside SJ_MATERIALIZATION_INFO structures. This could cause parts of one plan to be used with another, which led get_best_combination() to constructing non-sensical join plans (and crash). Fixed by saving/restoring SJM parts of the query plans. - check_and_do_in_subquery_rewrites() will not set SUBS_MATERIALIZATION flag when it records that the subquery predicate is to be converted into semi-join. If convert_join_subqueries_to_semijoins() later decides not to convert to semi-join, let it set SUBS_MATERIALIZATION flag, if appropriate.
2011-10-01 00:10:03 +04:00
#
# BUG#860553: Crash in create_ref_for_key with semijoin + materialization
#
CREATE TABLE t1 (f1 int) ;
CREATE TABLE t2 (f5 varchar(52) NOT NULL) ;
CREATE TABLE t3 (f1 varchar(3), f4 varchar(52) , KEY (f4), PRIMARY KEY (f1));
CREATE TABLE t4 (f3 int, KEY (f3));
INSERT INTO t4 VALUES (17),(20);
CREATE TABLE t5 (f2 int);
INSERT INTO t5 VALUES (0),(0);
SELECT *
FROM t1
JOIN t2
ON ( t2.f5 ) IN (
SELECT t3.f4
FROM t3
WHERE ( 1 ) IN (
SELECT t4.f3
FROM t4 , t5
)
);
f1 f5
DROP TABLE t1, t2, t3, t4, t5;
BUG#901032: Wrong result for MIN/MAX on an indexed column with materialization and semijoin - opt_sum_query() should not assume that join tables from sj-materialization have known numbers of rows.
2011-12-08 02:12:48 +04:00
#
BUG#868908: Crash in check_simple_equality() with semijoin + materialization + prepared statement - Part 1 of the fix: for semi-join merged subqueries, calling child_join->optimize() until we're done with all PS-lifetime optimizations in the parent.
2011-12-07 01:03:00 +04:00
# BUG#868908: Crash in check_simple_equality() with semijoin + materialization + prepared statement
#
CREATE TABLE t1 ( a int );
CREATE TABLE t3 ( b int, c int) ;
CREATE TABLE t2 ( a int ) ;
CREATE TABLE t4 ( a int , c int) ;
PREPARE st1 FROM "
SELECT STRAIGHT_JOIN *
FROM t1
WHERE ( 3 ) IN (
SELECT t3.b
FROM t3
LEFT JOIN (
t2 STRAIGHT_JOIN t4 ON ( t4.c = t2.a )
) ON ( t4.a = t3.c )
);
";
EXECUTE st1;
a
EXECUTE st1;
a
DROP TABLE t1,t2,t3,t4;
Merge fix for BUG#868908
2011-12-08 02:47:54 +04:00
#
BUG#901032: Wrong result for MIN/MAX on an indexed column with materialization and semijoin - opt_sum_query() should not assume that join tables from sj-materialization have known numbers of rows.
2011-12-08 02:12:48 +04:00
# BUG#901032: Wrong result for MIN/MAX on an indexed column with materialization and semijoin
#
CREATE TABLE t1 ( a INT, KEY(a) );
INSERT INTO t1 VALUES (1);
CREATE TABLE t2 ( b INT );
INSERT INTO t2 VALUES (2);
CREATE TABLE t3 ( c INT );
INSERT INTO t3 VALUES (2);
SELECT MIN(a) FROM t1, t2 WHERE b IN (SELECT c FROM t3 GROUP BY c);
MIN(a)
1
DROP TABLE t1,t2,t3;
BUG#902632: Crash or invalid read at st_join_table::cleanup, st_table::disable_keyread - Do a "more thorough" cleanup of SJ-Materialization join tab in JOIN_TAB::cleanup. The bug was due to the fact that JOIN_TAB::cleanup() may be called multiple times for the same tab if the join has grouping.
2011-12-14 02:15:15 +04:00
#
Merge
2011-12-14 04:56:54 +04:00
#
BUG#902632: Crash or invalid read at st_join_table::cleanup, st_table::disable_keyread - Do a "more thorough" cleanup of SJ-Materialization join tab in JOIN_TAB::cleanup. The bug was due to the fact that JOIN_TAB::cleanup() may be called multiple times for the same tab if the join has grouping.
2011-12-14 02:15:15 +04:00
# BUG#902632: Crash or invalid read at st_join_table::cleanup, st_table::disable_keyread
#
CREATE TABLE t1 ( a INT );
INSERT INTO t1 VALUES (1), (2);
CREATE TABLE t2 ( b INT );
INSERT INTO t2 VALUES (3), (4);
CREATE TABLE t3 ( c INT );
INSERT INTO t3 VALUES (5), (6);
SELECT * FROM t1 WHERE EXISTS (
SELECT DISTINCT b FROM t2
WHERE b <= a
AND b IN ( SELECT c FROM t3 GROUP BY c )
);
a
DROP TABLE t1,t2,t3;
Merge
2011-12-14 04:56:54 +04:00
#
BUG#901506: Crash in TABLE_LIST::print on EXPLAIN EXTENDED - Let JTBM optimization code handle the case where the subquery is degenerate and doesn't have a join query plan. Regular materialization would fall back to IN->EXISTS for such cases. Semi-Join materialization does not have such option, instead we introduce and use "constant JTBM join tabs".
2011-12-14 04:39:29 +04:00
# BUG#901506: Crash in TABLE_LIST::print on EXPLAIN EXTENDED
#
CREATE TABLE t1 ( a INT, KEY(a) );
INSERT INTO t1 VALUES (8);
EXPLAIN EXTENDED
SELECT * FROM t1
WHERE a IN ( SELECT MIN(a) FROM t1 );
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 system NULL NULL NULL NULL 1 100.00
Merge 5.2->5.3 in preparation for the release of mariadb-5.3.4-rc.
2012-02-01 15:48:02 -08:00
2 SUBQUERY NULL NULL NULL NULL NULL NULL NULL NULL Select tables optimized away
BUG#901506: Crash in TABLE_LIST::print on EXPLAIN EXTENDED - Let JTBM optimization code handle the case where the subquery is degenerate and doesn't have a join query plan. Regular materialization would fall back to IN->EXISTS for such cases. Semi-Join materialization does not have such option, instead we introduce and use "constant JTBM join tabs".
2011-12-14 04:39:29 +04:00
Warnings:
5.3 merge
2012-01-13 15:50:02 +01:00
Note 1003 select 8 AS `a` from dual where <expr_cache><8>(<in_optimizer>(8,<exists>(select min(`test`.`t1`.`a`) from `test`.`t1` having (<cache>(8) = <ref_null_helper>(min(`test`.`t1`.`a`))))))
BUG#901506: Crash in TABLE_LIST::print on EXPLAIN EXTENDED - Let JTBM optimization code handle the case where the subquery is degenerate and doesn't have a join query plan. Regular materialization would fall back to IN->EXISTS for such cases. Semi-Join materialization does not have such option, instead we introduce and use "constant JTBM join tabs".
2011-12-14 04:39:29 +04:00
DROP TABLE t1;
BUG#904432: Wrong result with LEFT JOIN, constant table, semijoin=ON,materialization=ON - Correct handling for SJ-Materialization + outer joins (details in the comments in the code)
2011-12-19 20:58:55 +04:00
#
# BUG#904432: Wrong result with LEFT JOIN, constant table, semijoin=ON,materialization=ON
#
CREATE TABLE t1 ( a INT ) ENGINE=MyISAM;
INSERT INTO t1 VALUES (4);
CREATE TABLE t2 ( b INT NOT NULL, c INT );
INSERT INTO t2 VALUES (4,2),(4,2),(4,4),(1,1);
SELECT * FROM t1 LEFT JOIN t2 ON ( a = b )
WHERE a IN ( SELECT c FROM t2 );
a b c
4 4 2
4 4 2
4 4 4
DROP TABLE t1,t2;
BUG#922254: Assertion `0' failed at item_cmpfunc.cc:5899: Item* Item_equal::get_first(JOIN_TAB*, Item*) Fixed Item* Item_equal::get_first(JOIN_TAB *context, Item *field_item) to work correctly in the case where: - context!= NO_PARTICULAR_TAB, it points to a table within SJ-Materialization nest - field_item points to an item_equal that has a constant Item_field but does not have any fields from tables that are within semi-join nests.
2012-01-27 17:35:26 +04:00
#
# BUG#922254: Assertion `0' failed at item_cmpfunc.cc:5899: Item* Item_equal::get_first(JOIN_TAB*, Item*)
#
CREATE TABLE t1 ( a VARCHAR(3) );
CREATE TABLE t2 ( b VARCHAR(3), c VARCHAR(8), KEY(c) );
INSERT INTO t2 VALUES ('USA','Abilene'),('USA','Akron');
EXPLAIN
SELECT * FROM
( SELECT * FROM t1 ) AS alias1,
t2 AS alias2
WHERE b = a AND a IN (
SELECT alias3.c
FROM t2 AS alias3, t2 AS alias4
WHERE alias4.c = alias3.b
);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL Impossible WHERE noticed after reading const tables
3 MATERIALIZED alias3 ALL NULL NULL NULL NULL 2
3 MATERIALIZED alias4 index c c 11 NULL 2 Using where; Using index; Using join buffer (flat, BNL join)
DROP TABLE t1,t2;
BUG#928048: Query containing IN subquery with OR in the where clause returns a wrong result - Make equality propagation work correctly when done inside the OR branches
2012-02-14 13:58:57 +04:00
#
# BUG#928048: Query containing IN subquery with OR in the where clause returns a wrong result
#
create table t1 (a int, b int);
insert into t1 values (7,5), (3,3), (5,4), (9,3);
create table t2 (a int, b int, index i_a(a));
insert into t2 values
(4,2), (7,9), (7,4), (3,1), (5,3), (3,1), (9,4), (8,1);
explain select * from t1 where t1.a in (select a from t2 where t2.a=7 or t2.b<=1);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 4 Using where
2 MATERIALIZED t2 ALL i_a NULL NULL NULL 8 Using where
select * from t1 where t1.a in (select a from t2 where t2.a=7 or t2.b<=1);
a b
7 5
3 3
drop table t1,t2;
BUG#933407: Valgrind warnings in mark_as_null_row with materialization+semijoin, STRAIGHT_JOIN, impossible WHERE - In return_zero_rows(), don't call mark_as_null_row() for semi-join materialized tables, because 1) they may have been already freed, and 2)there is no real need to call mark_as_null_row() for them.
2012-02-20 15:30:54 +04:00
#
# BUG#933407: Valgrind warnings in mark_as_null_row with materialization+semijoin, STRAIGHT_JOIN, impossible WHERE
#
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (0),(8);
SELECT STRAIGHT_JOIN MIN(a) FROM t1
WHERE a IN (
SELECT a FROM t1
WHERE 'condition'='impossible'
);
MIN(a)
NULL
DROP TABLE t1;
Update test results.
2012-02-25 01:42:28 +04:00
#
# BUG#938131: Subquery materialization is not used in CREATE TABLE SELECT
#
CREATE TABLE t1(a int);
INSERT INTO t1 values(1),(2);
CREATE TABLE t2(a int);
INSERT INTO t2 values(1),(2);
# Should use Materialization:
EXPLAIN SELECT * FROM t1 WHERE a IN (SELECT * FROM t2 GROUP BY a HAVING a > 1);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 2 Using where
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 2 Using temporary
flush status;
CREATE TABLE t3 SELECT * FROM t1 WHERE a IN (SELECT * FROM t2 GROUP BY a HAVING a > 1);
SHOW STATUS LIKE 'Created_tmp_tables';
Variable_name Value
Created_tmp_tables 3
DROP TABLE t1,t2,t3;
Merge.
2012-02-24 18:35:58 -08:00
#
Fixed LP bug #939009. The result of materialization of the right part of an IN subquery predicate is placed into a temporary table. Each row of the materialized table is distinct. A unique key over all fields of the temporary table is defined and created. It allows to perform key look-ups into the table. The table created for a materialized subquery can be accessed by key as any other table. The function best_access-path search for the best access to join a table to a given partial join. With some where conditions this function considers a possibility of a ref_or_null access. If such access employs the unique key on the temporary table then when estimating the cost this access the function tries to use the array rec_per_key. Yet, such array is not built for this unique key. This causes a crash of the server. Rows returned by the subquery that contain nulls don't have to be placed into temporary table, as they cannot be match any row produced by the left part of the subquery predicate. So all fields of the temporary table can be defined as non-nullable. In this case any ref_or_null access to the temporary table does not make any sense and it does not make sense to estimate such an access. The fix makes sure that the temporary table for a materialized IN subquery is defined with columns that are all non-nullable. The also ensures that any row with nulls returned by the subquery is not placed into the temporary table.
2012-02-24 16:50:22 -08:00
# BUG#939009: Crash with aggregate function in IN subquery
#
SET @save_optimizer_switch=@@optimizer_switch;
SET optimizer_switch='materialization=on,semijoin=on';
CREATE TABLE t1 (a int, b int);
INSERT INTO t1 VALUES (7,1), (4,2), (7,7);
CREATE TABLE t2 ( c INT );
INSERT INTO t2 VALUES (4), (7), (6);
EXPLAIN EXTENDED
SELECT * FROM t1
WHERE a IN (SELECT MAX(c) FROM t2) AND b=7 AND (a IS NULL OR a=b);
id select_type table type possible_keys key key_len ref rows filtered Extra
Fixed LP bug #943543. This bug appeared after the patch for bug 939009 that in the function merge_key_fields forgot to reset a proper value for the val field in the result of the merge operation of the key field created for a regular key access and the key field created to look for a NULL key. Adjusted the results of the test case for bug 939009 that actually were incorrect.
2012-02-29 23:28:16 -08:00
1 PRIMARY <subquery2> const distinct_key distinct_key 4 const 1 100.00
Fixed LP bug #939009. The result of materialization of the right part of an IN subquery predicate is placed into a temporary table. Each row of the materialized table is distinct. A unique key over all fields of the temporary table is defined and created. It allows to perform key look-ups into the table. The table created for a materialized subquery can be accessed by key as any other table. The function best_access-path search for the best access to join a table to a given partial join. With some where conditions this function considers a possibility of a ref_or_null access. If such access employs the unique key on the temporary table then when estimating the cost this access the function tries to use the array rec_per_key. Yet, such array is not built for this unique key. This causes a crash of the server. Rows returned by the subquery that contain nulls don't have to be placed into temporary table, as they cannot be match any row produced by the left part of the subquery predicate. So all fields of the temporary table can be defined as non-nullable. In this case any ref_or_null access to the temporary table does not make any sense and it does not make sense to estimate such an access. The fix makes sure that the temporary table for a materialized IN subquery is defined with columns that are all non-nullable. The also ensures that any row with nulls returned by the subquery is not placed into the temporary table.
2012-02-24 16:50:22 -08:00
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 100.00 Using where; Using join buffer (flat, BNL join)
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 3 100.00
Warnings:
MDEV-15475: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed on EXPLAIN EXTENDED with constant table and view Print constant ISNULL value independent. Fix of printing of view FRM and CREATE VIEW output
2018-08-06 15:50:22 +02:00
Note 1003 select `test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b` from <materialize> (select max(`test`.`t2`.`c`) from `test`.`t2`) join `test`.`t1` where ((`test`.`t1`.`b` = 7) and (`test`.`t1`.`a` = `<subquery2>`.`MAX(c)`) and (<cache>(isnull(/*always not null*/ 1)) or (`<subquery2>`.`MAX(c)` = 7)))
Fixed LP bug #939009. The result of materialization of the right part of an IN subquery predicate is placed into a temporary table. Each row of the materialized table is distinct. A unique key over all fields of the temporary table is defined and created. It allows to perform key look-ups into the table. The table created for a materialized subquery can be accessed by key as any other table. The function best_access-path search for the best access to join a table to a given partial join. With some where conditions this function considers a possibility of a ref_or_null access. If such access employs the unique key on the temporary table then when estimating the cost this access the function tries to use the array rec_per_key. Yet, such array is not built for this unique key. This causes a crash of the server. Rows returned by the subquery that contain nulls don't have to be placed into temporary table, as they cannot be match any row produced by the left part of the subquery predicate. So all fields of the temporary table can be defined as non-nullable. In this case any ref_or_null access to the temporary table does not make any sense and it does not make sense to estimate such an access. The fix makes sure that the temporary table for a materialized IN subquery is defined with columns that are all non-nullable. The also ensures that any row with nulls returned by the subquery is not placed into the temporary table.
2012-02-24 16:50:22 -08:00
SELECT * FROM t1
WHERE a IN (SELECT MAX(c) FROM t2) AND b=7 AND (a IS NULL OR a=b);
a b
Fixed LP bug #943543. This bug appeared after the patch for bug 939009 that in the function merge_key_fields forgot to reset a proper value for the val field in the result of the merge operation of the key field created for a regular key access and the key field created to look for a NULL key. Adjusted the results of the test case for bug 939009 that actually were incorrect.
2012-02-29 23:28:16 -08:00
7 7
Fixed LP bug #939009. The result of materialization of the right part of an IN subquery predicate is placed into a temporary table. Each row of the materialized table is distinct. A unique key over all fields of the temporary table is defined and created. It allows to perform key look-ups into the table. The table created for a materialized subquery can be accessed by key as any other table. The function best_access-path search for the best access to join a table to a given partial join. With some where conditions this function considers a possibility of a ref_or_null access. If such access employs the unique key on the temporary table then when estimating the cost this access the function tries to use the array rec_per_key. Yet, such array is not built for this unique key. This causes a crash of the server. Rows returned by the subquery that contain nulls don't have to be placed into temporary table, as they cannot be match any row produced by the left part of the subquery predicate. So all fields of the temporary table can be defined as non-nullable. In this case any ref_or_null access to the temporary table does not make any sense and it does not make sense to estimate such an access. The fix makes sure that the temporary table for a materialized IN subquery is defined with columns that are all non-nullable. The also ensures that any row with nulls returned by the subquery is not placed into the temporary table.
2012-02-24 16:50:22 -08:00
EXPLAIN
SELECT * FROM t1
WHERE a IN (SELECT MAX(c) FROM t2 WHERE c < 4) AND b=7 AND (a IS NULL OR a=b);
id select_type table type possible_keys key key_len ref rows Extra
Fixed LP bug #943543. This bug appeared after the patch for bug 939009 that in the function merge_key_fields forgot to reset a proper value for the val field in the result of the merge operation of the key field created for a regular key access and the key field created to look for a NULL key. Adjusted the results of the test case for bug 939009 that actually were incorrect.
2012-02-29 23:28:16 -08:00
1 PRIMARY <subquery2> const distinct_key distinct_key 4 const 1
Fixed LP bug #939009. The result of materialization of the right part of an IN subquery predicate is placed into a temporary table. Each row of the materialized table is distinct. A unique key over all fields of the temporary table is defined and created. It allows to perform key look-ups into the table. The table created for a materialized subquery can be accessed by key as any other table. The function best_access-path search for the best access to join a table to a given partial join. With some where conditions this function considers a possibility of a ref_or_null access. If such access employs the unique key on the temporary table then when estimating the cost this access the function tries to use the array rec_per_key. Yet, such array is not built for this unique key. This causes a crash of the server. Rows returned by the subquery that contain nulls don't have to be placed into temporary table, as they cannot be match any row produced by the left part of the subquery predicate. So all fields of the temporary table can be defined as non-nullable. In this case any ref_or_null access to the temporary table does not make any sense and it does not make sense to estimate such an access. The fix makes sure that the temporary table for a materialized IN subquery is defined with columns that are all non-nullable. The also ensures that any row with nulls returned by the subquery is not placed into the temporary table.
2012-02-24 16:50:22 -08:00
1 PRIMARY t1 ALL NULL NULL NULL NULL 3 Using where; Using join buffer (flat, BNL join)
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 3 Using where
SELECT * FROM t1
WHERE a IN (SELECT MAX(c) FROM t2 WHERE c < 4) AND b=7 AND (a IS NULL OR a=b);
a b
SET optimizer_switch=@save_optimizer_switch;
DROP TABLE t1,t2;
Fixed LP bug #946055. The function create_hj_key_for_table() that builds the descriptor of the hash join key to access a table of a materialized subquery must ignore any equi-join predicate depending on the tables not belonging to the subquery.
2012-03-05 20:32:28 -08:00
#
# BUG#946055: Crash with semijoin IN subquery when hash join is used
#
CREATE TABLE t1 (a int);
INSERT INTO t1 VALUES (7);
CREATE TABLE t2 (b int, c int, d varchar(1), e varchar(1), KEY (c), KEY (d, c));
INSERT INTO t2 VALUES
(4,2,'v','v'), (6,1,'v','v'), (0,5,'x','x'), (7,1,'x','x'),
(7,3,'i','i'), (7,1,'e','e'), (1,4,'p','p'), (1,2,'j','j');
SET @save_optimizer_switch=@@optimizer_switch;
SET @save_join_cache_level=@@join_cache_level;
SET join_cache_level=2;
EXPLAIN
SELECT a, c FROM t1, t2
WHERE (a, c) IN (SELECT s1.b, s1.c FROM t2 AS s1, t2 AS s2
WHERE s2.d = s1.e AND s1.e = (SELECT MAX(e) FROM t2));
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 system NULL NULL NULL NULL 1
1 PRIMARY t2 index NULL c 5 NULL 8 Using where; Using index
Fix for bug lp:944706, task MDEV-193 The patch enables back constant subquery execution during query optimization after it was disabled during the development of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION). The main idea is that constant subqueries are allowed to be executed during optimization if their execution is not expensive. The approach is as follows: - Constant subqueries are recursively optimized in the beginning of JOIN::optimize of the outer query. This is done by the new method JOIN::optimize_constant_subqueries(). This is done so that the cost of executing these queries can be estimated. - Optimization of the outer query proceeds normally. During this phase the optimizer may request execution of non-expensive constant subqueries. Each place where the optimizer may potentially execute an expensive expression is guarded with the predicate Item::is_expensive(). - The implementation of Item_subselect::is_expensive has been extended to use the number of examined rows (estimated by the optimizer) as a way to determine whether the subquery is expensive or not. - The new system variable "expensive_subquery_limit" controls how many examined rows are considered to be not expensive. The default is 100. In addition, multiple changes were needed to make this solution work in the light of the changes made by MWL#89. These changes were needed to fix various crashes and wrong results, and legacy bugs discovered during development.
2012-05-17 13:46:05 +03:00
2 MATERIALIZED s2 ref d d 4 const 2 Using where; Using index
Fixed LP bug #946055. The function create_hj_key_for_table() that builds the descriptor of the hash join key to access a table of a materialized subquery must ignore any equi-join predicate depending on the tables not belonging to the subquery.
2012-03-05 20:32:28 -08:00
2 MATERIALIZED s1 ALL NULL NULL NULL NULL 8 Using where; Using join buffer (flat, BNL join)
3 SUBQUERY t2 ALL NULL NULL NULL NULL 8
SELECT a, c FROM t1, t2
WHERE (a, c) IN (SELECT s1.b, s1.c FROM t2 AS s1, t2 AS s2
WHERE s2.d = s1.e AND s1.e = (SELECT MAX(e) FROM t2));
a c
7 1
7 1
7 1
SET optimizer_switch='join_cache_hashed=on';
SET join_cache_level=4;
EXPLAIN
SELECT a, c FROM t1, t2
WHERE (a, c) IN (SELECT s1.b, s1.c FROM t2 AS s1, t2 AS s2
WHERE s2.d = s1.e AND s1.e = (SELECT MAX(e) FROM t2));
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 system NULL NULL NULL NULL 1
1 PRIMARY t2 index NULL c 5 NULL 8 Using where; Using index
Fix for bug lp:944706, task MDEV-193 The patch enables back constant subquery execution during query optimization after it was disabled during the development of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION). The main idea is that constant subqueries are allowed to be executed during optimization if their execution is not expensive. The approach is as follows: - Constant subqueries are recursively optimized in the beginning of JOIN::optimize of the outer query. This is done by the new method JOIN::optimize_constant_subqueries(). This is done so that the cost of executing these queries can be estimated. - Optimization of the outer query proceeds normally. During this phase the optimizer may request execution of non-expensive constant subqueries. Each place where the optimizer may potentially execute an expensive expression is guarded with the predicate Item::is_expensive(). - The implementation of Item_subselect::is_expensive has been extended to use the number of examined rows (estimated by the optimizer) as a way to determine whether the subquery is expensive or not. - The new system variable "expensive_subquery_limit" controls how many examined rows are considered to be not expensive. The default is 100. In addition, multiple changes were needed to make this solution work in the light of the changes made by MWL#89. These changes were needed to fix various crashes and wrong results, and legacy bugs discovered during development.
2012-05-17 13:46:05 +03:00
2 MATERIALIZED s2 ref d d 4 const 2 Using where; Using index
2 MATERIALIZED s1 ALL NULL NULL NULL NULL 8 Using where; Using join buffer (flat, BNL join)
Fixed LP bug #946055. The function create_hj_key_for_table() that builds the descriptor of the hash join key to access a table of a materialized subquery must ignore any equi-join predicate depending on the tables not belonging to the subquery.
2012-03-05 20:32:28 -08:00
3 SUBQUERY t2 ALL NULL NULL NULL NULL 8
SELECT a, c FROM t1, t2
WHERE (a, c) IN (SELECT s1.b, s1.c FROM t2 AS s1, t2 AS s2
WHERE s2.d = s1.e AND s1.e = (SELECT MAX(e) FROM t2));
a c
7 1
7 1
7 1
SET optimizer_switch=@save_optimizer_switch;
SET join_cache_level=@save_join_cache_level;
DROP TABLE t1,t2;
BUG#952297: Server crashes on 2nd execution of PS in Field::is_null with semijoin+materialization - The bug would show up - when using PS (so that we get re-execution) - the left_expr of the subquery is a reference to viewname.column_name, so that it crashes when one tries to use it without having called fix_fields for it. - when using SJ-Materialization, which makes use of sj_subq_pred->left_expr expression - The fix is to have setup_conds() fix sj_subq_pred->left_expr for semi-join nests it finds.
2012-03-12 17:41:22 +04:00
#
# BUG#952297: Server crashes on 2nd execution of PS in Field::is_null with semijoin+materialization
#
CREATE TABLE t1 ( a VARCHAR(1) );
INSERT INTO t1 VALUES ('y'),('z');
CREATE TABLE t2 ( b VARCHAR(1), c VARCHAR(1) );
INSERT INTO t2 VALUES ('v','v'),('v','v');
CREATE VIEW v2 AS SELECT * FROM t2;
PREPARE ps FROM '
SELECT a FROM t1, v2
WHERE ( c, b ) IN ( SELECT b, b FROM t2 )
GROUP BY a ';
EXECUTE ps;
a
y
z
EXECUTE ps;
a
y
z
DROP VIEW v2;
DROP TABLE t1, t2;
5.2 merge
2012-05-20 14:57:29 +02:00
#
# BUG#1000269: Wrong result (extra rows) with semijoin+materialization, IN subqueries, join_cache_level>0
#
CREATE TABLE t1 (a1 VARCHAR(1), a2 VARCHAR(1)) ENGINE=MyISAM;
INSERT INTO t1 VALUES ('b','b'),('e','e');
CREATE TABLE t2 (b1 VARCHAR(1), b2 VARCHAR(1), KEY(b1)) ENGINE=MyISAM;
INSERT INTO t2 VALUES ('v','v'),('s','s'),('l','l'), ('y','y'),('c','c'),('i','i');
SELECT * FROM t1, t2 WHERE b1 IN ( SELECT b2 FROM t2 WHERE b1 > 'o' ) AND ( b1 < 'l' OR a1 IN ('b','c') );
a1 a2 b1 b2
b b v v
b b s s
b b y y
DROP TABLE t1,t2;
MDEV-4465: Reproducible crash (mysqld got signal 11) in multi_delete::initialize_tables... - make multi_delete::initialize_tables() take into account that the JOIN structure may have semi-join nests (which are not fully initialized when this function is called, they have tab->table=NULL which caused the crash) - Also checked multi_update::initialize_tables(): it has a different logic and needed no fixing.
2013-05-03 00:10:43 +04:00
#
# MDEV-4465: Reproducible crash (mysqld got signal 11) in multi_delete::initialize_tables with semijoin+materialization
#
CREATE TABLE t1 (
id int(11) NOT NULL
);
CREATE TABLE t2 (
id int(11) NOT NULL,
a_id int(11) DEFAULT NULL
);
insert into t1 values (1), (2), (3);
insert into t2 values (1, 1), (2, 1), (3, 1), (4, 2), (5, 3), (6, 3), (7, 3);
delete t2 from t2 where a_id in (select * from (select t1.id from t1 limit 2) as x);
drop table t1,t2;
BUG#860553: Crash in create_ref_for_key with semijoin + materialization - The problem was that JOIN::save/restore_query_plan() did not save/restore parts of the query plan that are located inside SJ_MATERIALIZATION_INFO structures. This could cause parts of one plan to be used with another, which led get_best_combination() to constructing non-sensical join plans (and crash). Fixed by saving/restoring SJM parts of the query plans. - check_and_do_in_subquery_rewrites() will not set SUBS_MATERIALIZATION flag when it records that the subquery predicate is to be converted into semi-join. If convert_join_subqueries_to_semijoins() later decides not to convert to semi-join, let it set SUBS_MATERIALIZATION flag, if appropriate.
2011-10-01 00:10:03 +04:00
# This must be at the end:
set optimizer_switch=@subselect_sj_mat_tmp;
Made join_cache_level == 2 by default.
2011-12-15 14:26:59 -08:00
set join_cache_level=@save_join_cache_level;
MDEV-4908: Assertion `((Item_cond *) cond)->functype() == ((Item_cond *) new_item)->functype()' fails on a query with IN and equal conditions, AND/OR, materialization+semijoin A new AND Item should be prepared (fix_field() call) before using.
2013-08-21 17:42:09 +03:00
#
# MDEV-4908: Assertion `((Item_cond *) cond)->functype() ==
# ((Item_cond *) new_item)->functype()' fails on a query with
# IN and equal conditions, AND/OR, materialization+semijoin
#
SET @save_optimizer_switch=@@optimizer_switch;
SET optimizer_switch = 'materialization=on,semijoin=on';
CREATE TABLE t1 (pk INT, a INT, b INT, PRIMARY KEY(pk)) ENGINE=MyISAM;
INSERT INTO t1 VALUES (1,3,5),(2,4,6);
SELECT * FROM t1 WHERE 8 IN ( SELECT MIN(pk) FROM t1 ) AND ( pk = a OR pk = b );
pk a b
drop table t1;
SET optimizer_switch=@save_optimizer_switch;
MDEV-5011: ERROR Plugin 'MEMORY' has ref_count=1 after shutdown for SJM queries - Provide a special execution path for cleanup of degenerate non-merged semi-join children of degenerate selects.
2013-09-12 13:53:13 +04:00
#
# MDEV-5011: ERROR Plugin 'MEMORY' has ref_count=1 after shutdown for SJM queries
#
CREATE TABLE t1 (pk INT, a INT, b INT, PRIMARY KEY(pk)) ENGINE=MyISAM;
INSERT INTO t1 VALUES (1,3,5),(2,4,6);
SELECT * FROM t1 WHERE 8 IN (SELECT MIN(pk) FROM t1) AND (pk = a OR pk = b);
pk a b
DROP TABLE t1;
MDEV-5368: Server crashes in Item_in_subselect::optimize on ... - convert_subq_to_sj() must connect child select's tables into parent select's TABLE_LIST::next_local chain. - The problem was that it took child's leaf_tables.head() which is different. This could cause certain tables (in this bug's case, child select's non-merged semi-join) not to be present in TABLE_LIST::next_local chain. Which would cause non-merged semi-join not to be initialized in setup_tables(), which would lead to NULL pointer dereference.
2014-01-23 21:26:04 +04:00
#
# MDEV-5368: Server crashes in Item_in_subselect::optimize on 2nd
# execution of PS with IN subqueries, materialization+semijoin
#
CREATE TABLE t1 (a INT) ENGINE=MyISAM;
INSERT INTO t1 VALUES (1),(3);
CREATE TABLE t2 (b INT) ENGINE=MyISAM;
CREATE ALGORITHM=MERGE VIEW v2 AS SELECT * FROM t2;
INSERT INTO t2 VALUES (8),(9);
PREPARE stmt FROM "
SELECT * FROM t1 WHERE 1 IN ( SELECT b FROM v2 WHERE 2 IN ( SELECT MAX(a) FROM t1 ) )
";
EXECUTE stmt;
a
EXECUTE stmt;
a
DROP TABLE t1, t2;
DROP VIEW v2;
MDEV-5811: Server crashes in best_access_path with materialization+semijoin and big_tables=ON - With big_tables=ON, materialized table will use Aria (or MyISAM) SE, which allows prefix key reads. However, the temp.table has rec_per_key=NULL which causes the optimizer to crash when attempting to read index statistics for a prefix index read. - Fixed by providing a rec_per_key array with zeros (i.e. "no statistics data")
2014-03-13 12:20:57 +01:00
#
# MDEV-5811: Server crashes in best_access_path with materialization+semijoin and big_tables=ON
#
SET @tmp_mdev5811= @@big_tables;
SET big_tables = ON;
CREATE TABLE t1 (a INT);
INSERT INTO t1 VALUES (1),(2);
CREATE TABLE t2 (b INT);
INSERT INTO t2 VALUES (3),(4);
SELECT * FROM t1 AS t1_1, t1 AS t1_2
WHERE ( t1_1.a, t1_2.a ) IN ( SELECT MAX(b), MIN(b) FROM t2 );
a a
DROP TABLE t1,t2;
SET big_tables=@tmp_mdev5811;
MDEV-4908: Assertion `((Item_cond *) cond)->functype() == ((Item_cond *) new_item)->functype()' fails on a query with IN and equal conditions, AND/OR, materialization+semijoin A new AND Item should be prepared (fix_field() call) before using.
2013-08-21 17:42:09 +03:00
# End of 5.3 tests
MDEV-5056: Wrong result (extra rows) with materialization+semijoin, IN subqueries Apply fix suggested by Igor: - When eliminate_item_equal() generates pair-wise equalities from a multi-equality, do generate a "bridge" equality between the first field inside SJM nest and the field that's first in the overall multi-equality.
2013-11-13 07:40:46 +04:00
#
# MDEV-5056: Wrong result (extra rows) with materialization+semijoin, IN subqueries
#
set @tmp_mdev5056=@@join_cache_level;
SET join_cache_level = 2;
CREATE TABLE t1 ( c1 VARCHAR(2), c2 VARCHAR(2), INDEX(c1) ) ENGINE=MyISAM;
INSERT INTO t1 VALUES
('JP','OM'),('VA','JP'),('CA','ML'),('ML','EG'),('DK','CA'),
('DK','QA'),('YE','PL'),('TR','ZW'),('DK','SK'),('SK','DK'),
('RO','ML'),('ML','BG'),('BG','ZW'),('ZW','GE'),('GE','JP'),
('PL','EG'),('QA','YE'),('WF','DK'),('DK','JP'),('EG','OM');
CREATE TABLE t2 ( c3 VARCHAR(2), c4 VARCHAR(2) ) ENGINE=MyISAM;
INSERT INTO t2 VALUES ('CA','ML'),('IN','HU'),('HU','IN');
SELECT * FROM t1 AS alias1, t1 AS alias2
WHERE ( alias2.c2, alias1.c1 ) IN ( SELECT c4, c3 FROM t2 ) AND alias1.c1 IN ( SELECT c2 FROM t1 );
c1 c2 c1 c2
CA ML CA ML
CA ML RO ML
DROP TABLE t1,t2;
set join_cache_level=@tmp_mdev5056;
MDEV-5368: Server crashes in Item_in_subselect::optimize on ... - convert_subq_to_sj() must connect child select's tables into parent select's TABLE_LIST::next_local chain. - The problem was that it took child's leaf_tables.head() which is different. This could cause certain tables (in this bug's case, child select's non-merged semi-join) not to be present in TABLE_LIST::next_local chain. Which would cause non-merged semi-join not to be initialized in setup_tables(), which would lead to NULL pointer dereference.
2014-01-23 15:41:51 +04:00
#
# MDEV-5368: Server crashes in Item_in_subselect::optimize on 2nd
# execution of PS with IN subqueries, materialization+semijoin
#
CREATE TABLE t1 (a INT) ENGINE=MyISAM;
INSERT INTO t1 VALUES (1),(3);
CREATE TABLE t2 (b INT) ENGINE=MyISAM;
CREATE ALGORITHM=MERGE VIEW v2 AS SELECT * FROM t2;
INSERT INTO t2 VALUES (8),(9);
PREPARE stmt FROM "
SELECT * FROM t1 WHERE 1 IN ( SELECT b FROM v2 WHERE 2 IN ( SELECT MAX(a) FROM t1 ) )
";
EXECUTE stmt;
a
EXECUTE stmt;
a
DROP TABLE t1, t2;
DROP VIEW v2;
MDEV-6289 : Unexpected results when querying information_schema - When traversing JOIN_TABs with first_linear_tab/next_linear_tab(), don't forget to enter the semi-join nest when it is the first table in the join order. Failure to do so could cause e.g. I_S tables not to be filled.
2014-07-23 19:53:29 +04:00
#
# MDEV-6289 : Unexpected results when querying information_schema
#
CREATE TABLE t1 (
id int(11) unsigned NOT NULL AUTO_INCREMENT,
db varchar(254) NOT NULL DEFAULT '',
PRIMARY KEY (id),
UNIQUE KEY db (db)
) DEFAULT CHARSET=utf8;
INSERT INTO t1 (db) VALUES ('mysqltest1'),('mysqltest2'),('mysqltest3'),('mysqltest4');
drop database if exists mysqltest1;
drop database if exists mysqltest2;
drop database if exists mysqltest3;
drop database if exists mysqltest4;
create database mysqltest1;
create database mysqltest2;
create database mysqltest3;
create database mysqltest4;
fix the test to pass on windows (lower_case_file_system)
2014-07-29 12:56:43 +02:00
SELECT db FROM t1 WHERE db IN (SELECT SCHEMA_NAME FROM information_schema.schemata) ORDER BY db DESC;
MDEV-6289 : Unexpected results when querying information_schema - When traversing JOIN_TABs with first_linear_tab/next_linear_tab(), don't forget to enter the semi-join nest when it is the first table in the join order. Failure to do so could cause e.g. I_S tables not to be filled.
2014-07-23 19:53:29 +04:00
db
mysqltest4
mysqltest3
mysqltest2
mysqltest1
EXPLAIN EXTENDED
fix the test to pass on windows (lower_case_file_system)
2014-07-29 12:56:43 +02:00
SELECT db FROM t1 WHERE db IN (SELECT SCHEMA_NAME FROM information_schema.schemata) ORDER BY db DESC;
MDEV-6289 : Unexpected results when querying information_schema - When traversing JOIN_TABs with first_linear_tab/next_linear_tab(), don't forget to enter the semi-join nest when it is the first table in the join order. Failure to do so could cause e.g. I_S tables not to be filled.
2014-07-23 19:53:29 +04:00
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY <subquery2> ALL distinct_key NULL NULL NULL 2 100.00 Using temporary; Using filesort
fix the test to pass on windows (lower_case_file_system)
2014-07-29 12:56:43 +02:00
1 PRIMARY t1 eq_ref db db 764 information_schema.schemata.SCHEMA_NAME 1 100.00 Using where; Using index
2 MATERIALIZED schemata ALL NULL NULL NULL NULL NULL NULL
MDEV-6289 : Unexpected results when querying information_schema - When traversing JOIN_TABs with first_linear_tab/next_linear_tab(), don't forget to enter the semi-join nest when it is the first table in the join order. Failure to do so could cause e.g. I_S tables not to be filled.
2014-07-23 19:53:29 +04:00
Warnings:
fix the test to pass on windows (lower_case_file_system)
2014-07-29 12:56:43 +02:00
Note 1003 select `test`.`t1`.`db` AS `db` from `test`.`t1` semi join (`information_schema`.`schemata`) where (`test`.`t1`.`db` = `information_schema`.`schemata`.`SCHEMA_NAME`) order by `test`.`t1`.`db` desc
MDEV-6289 : Unexpected results when querying information_schema - When traversing JOIN_TABs with first_linear_tab/next_linear_tab(), don't forget to enter the semi-join nest when it is the first table in the join order. Failure to do so could cause e.g. I_S tables not to be filled.
2014-07-23 19:53:29 +04:00
drop table t1;
drop database mysqltest1;
drop database mysqltest2;
drop database mysqltest3;
drop database mysqltest4;
Problem was that for cases like: SELECT ... WHERE XX IN (SELECT YY) this was transformed to something like: SELECT ... WHERE IF_EXISTS(SELECT ... HAVING XX=YY) The bug was that for normal execution XX was fixed in the original outer SELECT context while in PS it was fixed in the sub query context and this confused the optimizer. Fixed by ensuring that XX is always fixed in the outer context.
2015-06-25 23:26:29 +03:00
#
# MDEV-7810 Wrong result on execution of a query as a PS
# (both 1st and further executions)
CREATE TABLE t1 (a INT NOT NULL) ENGINE=MyISAM;
INSERT INTO t1 VALUES (0),(8);
MDEV-7810 Wrong result on execution of a query as a PS (both 1st and further executions) Alternative fix that doesn't cause view.test crash in --ps: Remember when Item_ref was fixed right in the constructor and did not have a full Item_ref::fix_fields() call. Later in PS/SP, after Item_ref::cleanup, we use this knowledge to avoid doing full fix_fields() for items that were never supposed to be fix_field'ed. Simplify the test case.
2015-07-31 10:13:01 +02:00
SELECT a FROM (SELECT DISTINCT * FROM t1) AS sq WHERE a IN (SELECT MIN(t2.a) FROM (t1 AS t2));
Problem was that for cases like: SELECT ... WHERE XX IN (SELECT YY) this was transformed to something like: SELECT ... WHERE IF_EXISTS(SELECT ... HAVING XX=YY) The bug was that for normal execution XX was fixed in the original outer SELECT context while in PS it was fixed in the sub query context and this confused the optimizer. Fixed by ensuring that XX is always fixed in the outer context.
2015-06-25 23:26:29 +03:00
a
0
PREPARE stmt FROM "
MDEV-7810 Wrong result on execution of a query as a PS (both 1st and further executions) Alternative fix that doesn't cause view.test crash in --ps: Remember when Item_ref was fixed right in the constructor and did not have a full Item_ref::fix_fields() call. Later in PS/SP, after Item_ref::cleanup, we use this knowledge to avoid doing full fix_fields() for items that were never supposed to be fix_field'ed. Simplify the test case.
2015-07-31 10:13:01 +02:00
SELECT a FROM (SELECT DISTINCT * FROM t1) AS sq WHERE a IN (SELECT MIN(t2.a) FROM (t1 AS t2))
Problem was that for cases like: SELECT ... WHERE XX IN (SELECT YY) this was transformed to something like: SELECT ... WHERE IF_EXISTS(SELECT ... HAVING XX=YY) The bug was that for normal execution XX was fixed in the original outer SELECT context while in PS it was fixed in the sub query context and this confused the optimizer. Fixed by ensuring that XX is always fixed in the outer context.
2015-06-25 23:26:29 +03:00
";
execute stmt;
a
0
execute stmt;
a
0
drop table t1;
Fixed the bug mdev-12429 and its duplicates mdev-12145 and mdev-9886. Also fixed a wrong result for a test case for mdev-7691 (the alternative one). The test cases for all these bug have materialized semi-joins used inside dependent sub-queries. The patch actually reverts the change inroduced by Monty in 2003. It looks like this change is not valid anymore after the implementation of semi-joins. Adjusted output from EXPLAIN for many other test cases.
2017-04-04 10:04:52 -07:00
#
# MDEV-12429: IN subquery used in WHERE of EXISTS subquery
#
CREATE TABLE t1 (
pk INT, f1 INT NOT NULL, f2 VARCHAR(3), f3 INT NULL, PRIMARY KEY(pk)) ENGINE=MyISAM;
INSERT INTO t1 VALUES (1,1,'foo',8), (2,5,'bar',7);
SELECT sq1.f2 FROM t1 AS sq1
WHERE EXISTS ( SELECT * FROM t1 AS sq2
WHERE sq1.`pk` IN ( SELECT f1 FROM t1 ) AND sq2.f1 = sq1.f1 );
f2
foo
EXPLAIN
SELECT sq1.f2 FROM t1 AS sq1
WHERE EXISTS ( SELECT * FROM t1 AS sq2
WHERE sq1.`pk` IN ( SELECT f1 FROM t1 ) AND sq2.f1 = sq1.f1 );
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY sq1 ALL NULL NULL NULL NULL 2 Using where
2 DEPENDENT SUBQUERY <subquery3> eq_ref distinct_key distinct_key 4 func 1
2 DEPENDENT SUBQUERY sq2 ALL NULL NULL NULL NULL 2 Using where; Using join buffer (flat, BNL join)
3 MATERIALIZED t1 ALL NULL NULL NULL NULL 2
# this checks the result set above
set @save_optimizer_switch= @@optimizer_switch;
set optimizer_switch= 'materialization=off,semijoin=off';
SELECT sq1.f2 FROM t1 AS sq1
WHERE EXISTS ( SELECT * FROM t1 AS sq2
WHERE sq1.`pk` IN ( SELECT f1 FROM t1 ) AND sq2.f1 = sq1.f1 );
f2
foo
set optimizer_switch= @save_optimizer_switch;
DROP TABLE t1;
#
# MDEV-12145: IN subquery used in WHERE of EXISTS subquery
#
CREATE TABLE t1 (f1 INT) ENGINE=MyISAM;
INSERT INTO t1 VALUES (4),(6);
CREATE TABLE t2 (i2 INT, KEY(i2)) ENGINE=MyISAM;
INSERT INTO t2 VALUES (8),(7),(1);
CREATE TABLE t3 (f3 INT, i3 INT, KEY(i3)) ENGINE=MyISAM;
INSERT INTO t3 VALUES (8,0),(6,3),(2,8),(3,8),(1,6),(0,0),(1,0),(1,5);
SELECT * FROM t1
WHERE EXISTS ( SELECT * FROM t2, t3
WHERE i3 = i2 AND f1 IN ( SELECT f3 FROM t3 ) );
f1
6
EXPLAIN EXTENDED
SELECT * FROM t1
WHERE EXISTS ( SELECT * FROM t2, t3
WHERE i3 = i2 AND f1 IN ( SELECT f3 FROM t3 ) );
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 2 100.00 Using where
2 DEPENDENT SUBQUERY <subquery3> eq_ref distinct_key distinct_key 4 func 1 100.00
2 DEPENDENT SUBQUERY t2 index i2 i2 5 NULL 3 100.00 Using where; Using index; Using join buffer (flat, BNL join)
2 DEPENDENT SUBQUERY t3 ref i3 i3 5 test.t2.i2 2 100.00 Using index
3 MATERIALIZED t3 ALL NULL NULL NULL NULL 8 100.00
Warnings:
Note 1276 Field or reference 'test.t1.f1' of SELECT #2 was resolved in SELECT #1
Note 1003 select `test`.`t1`.`f1` AS `f1` from `test`.`t1` where <expr_cache><`test`.`t1`.`f1`>(exists(select 1 from `test`.`t2` semi join (`test`.`t3`) join `test`.`t3` where ((`test`.`t3`.`i3` = `test`.`t2`.`i2`) and (`test`.`t1`.`f1` = `test`.`t3`.`f3`))))
# this checks the result set above
set @save_optimizer_switch= @@optimizer_switch;
set optimizer_switch= 'materialization=off,semijoin=off';
SELECT * FROM t1
WHERE EXISTS ( SELECT * FROM t2, t3
WHERE i3 = i2 AND f1 IN ( SELECT f3 FROM t3 ) );
f1
6
set optimizer_switch= @save_optimizer_switch;
DROP TABLE t1,t2,t3;
#
# MDEV-9686: IN subquery used in WHERE of a subquery from select list
#
CREATE TABLE t1 (pk INT PRIMARY KEY, f1 INT);
INSERT INTO t1 VALUES (1, 4),(2, 3),(3, 3),(4, 6),(5, 3);
CREATE TABLE t2 (f2 INT);
INSERT INTO t2 VALUES (1),(2),(3),(4),(5);
# t1.pk is always IN ( SELECT f2 FROM t2 ),
# so the IN condition should be true for every row,
# and thus COUNT(*) should always return 5
SELECT pk, f1, ( SELECT COUNT(*) FROM t2
WHERE t1.pk IN ( SELECT f2 FROM t2 ) ) AS sq FROM t1;
pk f1 sq
1 4 5
2 3 5
3 3 5
4 6 5
5 3 5
EXPLAIN EXTENDED
SELECT pk, f1, ( SELECT COUNT(*) FROM t2
WHERE t1.pk IN ( SELECT f2 FROM t2 ) ) AS sq FROM t1;
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 5 100.00
2 DEPENDENT SUBQUERY <subquery3> eq_ref distinct_key distinct_key 4 func 1 100.00
2 DEPENDENT SUBQUERY t2 ALL NULL NULL NULL NULL 5 100.00 Using join buffer (flat, BNL join)
3 MATERIALIZED t2 ALL NULL NULL NULL NULL 5 100.00
Warnings:
Note 1276 Field or reference 'test.t1.pk' of SELECT #2 was resolved in SELECT #1
Note 1003 select `test`.`t1`.`pk` AS `pk`,`test`.`t1`.`f1` AS `f1`,<expr_cache><`test`.`t1`.`pk`>((select count(0) from `test`.`t2` semi join (`test`.`t2`) where (`test`.`t1`.`pk` = `test`.`t2`.`f2`))) AS `sq` from `test`.`t1`
# this checks the result set above
set @save_optimizer_switch= @@optimizer_switch;
set optimizer_switch= 'materialization=off,semijoin=off';
SELECT pk, f1, ( SELECT COUNT(*) FROM t2
WHERE t1.pk IN ( SELECT f2 FROM t2 ) ) AS sq FROM t1;
pk f1 sq
1 4 5
2 3 5
3 3 5
4 6 5
5 3 5
set optimizer_switch= @save_optimizer_switch;
DROP TABLE t1,t2;
Fixed the bug mdev-12838. If the optimizer chose an execution plan where a semi-join nest were materialized and the result of materialization was scanned to access other tables by ref access it could build a key over columns of the tables from the nest that were actually inaccessible. The patch performs a proper check whether a key that uses columns of the tables from a materialized semi-join nest can be employed to access outer tables.
2017-06-07 12:45:09 -07:00
#
# mdev-12838: scan of materialized of semi-join subquery in join
#
set @save_optimizer_switch=@@optimizer_switch;
CREATE TABLE t1 (
dispatch_group varchar(32),
assignment_group varchar(32),
sys_id char(32),
PRIMARY KEY (sys_id),
KEY idx1 (dispatch_group),
KEY idx2 (assignment_group)
) ENGINE=MyISAM;
CREATE TABLE t2 (
ugroup varchar(32),
user varchar(32),
sys_id char(32),
PRIMARY KEY (sys_id),
KEY idx3 (ugroup),
KEY idx4 (user)
) ENGINE=MyISAM;
CREATE TABLE t3 (
type mediumtext,
sys_id char(32),
PRIMARY KEY (sys_id)
) ENGINE=MyISAM;
set optimizer_switch='materialization=off';
explain SELECT t1.assignment_group
FROM t1, t3
WHERE t1.assignment_group = t3.sys_id AND
t1.dispatch_group IN
(SELECT t2.ugroup
FROM t2, t3 t3_i
WHERE t2.ugroup = t3_i.sys_id AND
t3_i.type LIKE '59e22fb137032000158bbfc8bcbe5d52' AND
t2.user = '86826bf03710200044e0bfc8bcbe5d79');
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t2 ref idx3,idx4 idx4 35 const 2 Using index condition; Using where; Start temporary
1 PRIMARY t3_i eq_ref PRIMARY PRIMARY 32 test.t2.ugroup 1 Using index condition; Using where
1 PRIMARY t1 ref idx1,idx2 idx1 35 test.t3_i.sys_id 2 Using index condition; Using where; End temporary
1 PRIMARY t3 eq_ref PRIMARY PRIMARY 32 test.t1.assignment_group 1 Using where; Using index
SELECT t1.assignment_group
FROM t1, t3
WHERE t1.assignment_group = t3.sys_id AND
t1.dispatch_group IN
(SELECT t2.ugroup
FROM t2, t3 t3_i
WHERE t2.ugroup = t3_i.sys_id AND
t3_i.type LIKE '59e22fb137032000158bbfc8bcbe5d52' AND
t2.user = '86826bf03710200044e0bfc8bcbe5d79');
assignment_group
df50316637232000158bbfc8bcbe5d23
e08fad2637232000158bbfc8bcbe5d39
ec70316637232000158bbfc8bcbe5d60
7b10fd2637232000158bbfc8bcbe5d30
ebb4620037332000158bbfc8bcbe5d89
set optimizer_switch='materialization=on';
explain SELECT t1.assignment_group
FROM t1, t3
WHERE t1.assignment_group = t3.sys_id AND
t1.dispatch_group IN
(SELECT t2.ugroup
FROM t2, t3 t3_i
WHERE t2.ugroup = t3_i.sys_id AND
t3_i.type LIKE '59e22fb137032000158bbfc8bcbe5d52' AND
t2.user = '86826bf03710200044e0bfc8bcbe5d79');
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <subquery2> ALL distinct_key NULL NULL NULL 2
1 PRIMARY t1 ref idx1,idx2 idx1 35 test.t2.ugroup 2 Using where
1 PRIMARY t3 eq_ref PRIMARY PRIMARY 32 test.t1.assignment_group 1 Using where; Using index
2 MATERIALIZED t2 ref idx3,idx4 idx4 35 const 2 Using index condition; Using where
2 MATERIALIZED t3_i eq_ref PRIMARY PRIMARY 32 test.t2.ugroup 1 Using index condition; Using where
SELECT t1.assignment_group
FROM t1, t3
WHERE t1.assignment_group = t3.sys_id AND
t1.dispatch_group IN
(SELECT t2.ugroup
FROM t2, t3 t3_i
WHERE t2.ugroup = t3_i.sys_id AND
t3_i.type LIKE '59e22fb137032000158bbfc8bcbe5d52' AND
t2.user = '86826bf03710200044e0bfc8bcbe5d79');
assignment_group
df50316637232000158bbfc8bcbe5d23
e08fad2637232000158bbfc8bcbe5d39
ec70316637232000158bbfc8bcbe5d60
7b10fd2637232000158bbfc8bcbe5d30
ebb4620037332000158bbfc8bcbe5d89
DROP TABLE t1,t2,t3;
set optimizer_switch=@save_optimizer_switch;
MDEV-16751: Server crashes in st_join_table::cleanup or TABLE_LIST::is_with_table_recursive_reference with join_cache_level>2 During muliple equality propagation for a query in which we have an IN subquery, the items in the select list of the subquery may not be part of the multiple equality because there might be another occurence of the same field in the where clause of the subquery. So we keyuse_is_valid_for_access_in_chosen_plan function which expects the items in the select list of the subquery to be same to the ones in the multiple equality (through these multiple equalities we create keyuse array). The solution would be that we expect the same field not the same Item because when we have SEMI JOIN MATERIALIZATION SCAN, we use copy back technique to copies back the materialised table fields to the original fields of the base tables.
2018-07-25 14:20:16 +05:30
#
# MDEV-16751: Server crashes in st_join_table::cleanup or
# TABLE_LIST::is_with_table_recursive_reference with join_cache_level>2
#
set @save_join_cache_level= @@join_cache_level;
set join_cache_level=4;
CREATE TABLE t1 ( id int NOT NULL);
INSERT INTO t1 VALUES (11),(12),(13),(14),(15),(16),(17),(18),(19);
CREATE TABLE t2 (i1 int NOT NULL, i2 int NOT NULL) ;
INSERT INTO t2 VALUES (11,11),(12,12),(13,13);
explain
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <subquery2> ALL distinct_key NULL NULL NULL 3
1 PRIMARY t1 hash_ALL NULL #hash#$hj 4 test.t2.i1 9 Using where; Using join buffer (flat, BNLH join)
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 3 Using where
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
1
1
1
1
set @@join_cache_level= @save_join_cache_level;
alter table t1 add key(id);
explain
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <subquery2> ALL distinct_key NULL NULL NULL 3
1 PRIMARY t1 ref id id 4 test.t2.i1 2 Using index
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 3 Using where
SELECT 1 FROM t1 where t1.id IN (SELECT t2.i1 FROM t2 WHERE t2.i1 = t2.i2);
1
1
1
1
drop table t1,t2;
MDEV-15454: Nested SELECT IN returns wrong results In this case we are setting the field Item_func_eq::in_eqaulity_no for the semi-join equalities. This helps us to remove these equalites as the inner tables are not available during parent select execution while the outer tables are not available during materialization phase. We only have it set for the equalites for the fields involved with the IN subquery and reset it for the equalities which do not belong to the IN subquery. For example in case of nested IN subqueries: SELECT t1.a FROM t1 WHERE t1.a IN (SELECT t2.a FROM t2 where t2.b IN (select t3.b from t3 where t3.c=27 )) there are two equalites involving the fields of the IN subquery 1) t2.b = t3.b : the field Item_func_eq::in_eqaulity_no is set when we merge the grandchild select into the child select 2) t1.a = t2.a : the field Item_func_eq::in_eqaulity_no is set when we merge the child select into the parent select But when we perform case 2) we should ensure that we reset the equalities in the child's WHERE clause.
2018-07-25 21:17:50 +05:30
#
# MDEV-15454: Nested SELECT IN returns wrong results
#
CREATE TABLE t1 ( a int NOT NULL PRIMARY KEY);
CREATE TABLE t2 ( a int, b int );
INSERT INTO t2 VALUES (7878, 96),(3465, 96),(1403, 96),(4189, 96),(8732, 96), (5,96);
CREATE TABLE t3 (c int unsigned NOT NULL, b int unsigned NOT NULL, PRIMARY KEY (c,b));
INSERT INTO t3 (c, b) VALUES (27, 96);
CREATE PROCEDURE prepare_data()
BEGIN
DECLARE i INT DEFAULT 1;
WHILE i < 1000 DO
INSERT INTO t1 (a) VALUES (i);
INSERT INTO t2 (a,b) VALUES (i,56);
INSERT INTO t3 (c,b) VALUES (i,i);
SET i = i + 1;
END WHILE;
END$$
CALL prepare_data();
SELECT t2.a FROM t2 WHERE t2.b IN (SELECT t3.b FROM t3 WHERE t3.c= 27);
a
7878
3465
1403
4189
8732
5
set @save_optimizer_switch= @@optimizer_switch;
SET optimizer_switch='materialization=off';
SELECT t1.a FROM t1
WHERE t1.a IN (SELECT t2.a FROM t2 WHERE t2.b IN (SELECT t3.b FROM t3 WHERE t3.c= 27)) LIMIT 5;
a
5
SET optimizer_switch='materialization=on';
SELECT t1.a FROM t1
WHERE t1.a IN (SELECT t2.a FROM t2 WHERE t2.b IN (SELECT t3.b FROM t3 WHERE t3.c= 27)) LIMIT 5;
a
5
drop procedure prepare_data;
set @@optimizer_switch= @save_optimizer_switch;
drop table t1,t2,t3;
Fix added along with a test for a case missed in the patch for MDEV-16751
2018-07-27 11:34:34 +05:30
CREATE TABLE t1 ( id int NOT NULL, key(id));
INSERT INTO t1 VALUES (11),(12),(13),(14),(15),(16),(17),(18),(19);
CREATE TABLE t2 (i1 int NOT NULL, i2 int NOT NULL);
INSERT INTO t2 VALUES (11,11),(12,12),(13,13);
CREATE VIEW v1 AS SELECT t2.i1 FROM t2 where t2.i1 = t2.i2;
explain SELECT 1 FROM t1 where t1.id IN (SELECT v1.i1 from v1);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <subquery2> ALL distinct_key NULL NULL NULL 3
1 PRIMARY t1 ref id id 4 test.t2.i1 2 Using index
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 3 Using where
SELECT 1 FROM t1 where t1.id IN (SELECT v1.i1 from v1);
1
1
1
1
drop table t1,t2;
drop view v1;
MDEV-19580 Unrelated JOINs corrupt usage of 'WHERE function() IN (subquery)' Handling of top level conjuncts in WHERE whose used_tables() contained RAND_TABLE_BIT in the function make_join_select() was incorrect. As a result if such a conjunct referred to fields non of which belonged to the last joined table it was pushed twice. (This could be seen for a test case from subselect.test whose output was changed after this patch had been applied. In 10.1 when running EXPLAIN FORMAT=JSON for the query from this test case we clearly see that one of the conjuncts is pushed twice.) This fact by itself was not good. Besides, if such a conjunct was pushed to a table that was the result of materialization of a semi-join the query could return a wrong result set. In particular we could watch it for queries with semi-join subqueries whose left parts used stored functions without "deterministic' specifier.
2019-06-09 10:39:52 -07:00
#
# MDEV-19580: function invocation in the left part of IN subquery
#
create table t1 (id int, a varchar(50), b int);
insert into t1 values
(1,'mrs',2), (2,'joe',2), (3,'paul',1), (4,'art',1);
create table t2 (id int, a varchar(50), x int);
insert into t2 values
(1,'grand',1),(2,'average',1),(3,'serf',0);
create table t3 (d1 date, d2 date, t1_id int, t2_id int );
insert into t3 values
('1972-01-01','1988-12-31',3,1), ('1972-01-01','1988-12-31',4,1),
('1972-01-01','1988-12-31',1,2), ('1972-01-01','1988-12-31',2,3);
create table t4 ( id int, a varchar(50) );
insert into t4 values
(1,'songwriter'),(2,'song character');
create function f1(who int, dt date) returns int
deterministic
begin
declare result int;
select t2_id into result from t3 where dt>=d1 and dt<=d2 and t1_id=who;
return result;
end$$
create function f2(who int, dt date) returns int
begin
declare result int;
select t2_id into result from t3 where dt>=d1 and dt<=d2 and t1_id=who;
return result;
end$$
# Deterministic function in left part of IN subquery: semi-join is OK
select * from t1
left join t4 on t1.b = t4.id
where f1(t1.id, '1980-01-01') in (select id from t2 where x=1);
id a b id a
3 paul 1 1 songwriter
4 art 1 1 songwriter
1 mrs 2 2 song character
explain extended select * from t1
left join t4 on t1.b = t4.id
where f1(t1.id, '1980-01-01') in (select id from t2 where x=1);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 4 100.00
1 PRIMARY <subquery2> eq_ref distinct_key distinct_key 4 func 1 100.00 Using where
1 PRIMARY t4 ALL NULL NULL NULL NULL 2 100.00 Using where; Using join buffer (flat, BNL join)
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Note 1003 select `test`.`t1`.`id` AS `id`,`test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b`,`test`.`t4`.`id` AS `id`,`test`.`t4`.`a` AS `a` from `test`.`t1` semi join (`test`.`t2`) left join `test`.`t4` on((`test`.`t4`.`id` = `test`.`t1`.`b`)) where ((`test`.`t2`.`x` = 1) and (`f1`(`test`.`t1`.`id`,'1980-01-01') = `test`.`t2`.`id`))
# Non-deterministic function in left part of IN subq: semi-join is OK
select * from t1
left join t4 on t1.b = t4.id
where f2(t1.id, '1980-01-01') in (select id from t2 where x=1);
id a b id a
3 paul 1 1 songwriter
4 art 1 1 songwriter
1 mrs 2 2 song character
explain extended select * from t1
left join t4 on t1.b = t4.id
where f2(t1.id, '1980-01-01') in (select id from t2 where x=1);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 4 100.00
1 PRIMARY <subquery2> eq_ref distinct_key distinct_key 4 func 1 100.00 Using where
1 PRIMARY t4 ALL NULL NULL NULL NULL 2 100.00 Using where; Using join buffer (flat, BNL join)
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 3 100.00 Using where
Warnings:
Note 1003 select `test`.`t1`.`id` AS `id`,`test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b`,`test`.`t4`.`id` AS `id`,`test`.`t4`.`a` AS `a` from `test`.`t1` semi join (`test`.`t2`) left join `test`.`t4` on((`test`.`t4`.`id` = `test`.`t1`.`b`)) where ((`test`.`t2`.`x` = 1) and (`f2`(`test`.`t1`.`id`,'1980-01-01') = `test`.`t2`.`id`))
select t1.*, t4.*,
(select max(t4.id) from t4 where t4.id=t1.b and sleep(0) = 0) as s
from t1 left join t4 on t1.b = t4.id
where f2(t1.id, '1980-01-01') in (select id from t2 where x=1);
id a b id a s
3 paul 1 1 songwriter 1
4 art 1 1 songwriter 1
1 mrs 2 2 song character 2
explain extended select t1.*, t4.*,
(select max(t4.id) from t4 where t4.id=t1.b and sleep(0) = 0) as s
from t1 left join t4 on t1.b = t4.id
where f2(t1.id, '1980-01-01') in (select id from t2 where x=1);
id select_type table type possible_keys key key_len ref rows filtered Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 4 100.00
1 PRIMARY <subquery3> eq_ref distinct_key distinct_key 4 func 1 100.00 Using where
1 PRIMARY t4 ALL NULL NULL NULL NULL 2 100.00 Using where; Using join buffer (flat, BNL join)
3 MATERIALIZED t2 ALL NULL NULL NULL NULL 3 100.00 Using where
2 DEPENDENT SUBQUERY t4 ALL NULL NULL NULL NULL 2 100.00 Using where
Warnings:
Note 1276 Field or reference 'test.t1.b' of SELECT #2 was resolved in SELECT #1
Note 1003 select `test`.`t1`.`id` AS `id`,`test`.`t1`.`a` AS `a`,`test`.`t1`.`b` AS `b`,`test`.`t4`.`id` AS `id`,`test`.`t4`.`a` AS `a`,(select max(`test`.`t4`.`id`) from `test`.`t4` where ((`test`.`t4`.`id` = `test`.`t1`.`b`) and (sleep(0) = 0))) AS `s` from `test`.`t1` semi join (`test`.`t2`) left join `test`.`t4` on((`test`.`t4`.`id` = `test`.`t1`.`b`)) where ((`test`.`t2`.`x` = 1) and (`f2`(`test`.`t1`.`id`,'1980-01-01') = `test`.`t2`.`id`))
drop function f1;
drop function f2;
drop table t1,t2,t3,t4;
MDEV-5056: Wrong result (extra rows) with materialization+semijoin, IN subqueries Apply fix suggested by Igor: - When eliminate_item_equal() generates pair-wise equalities from a multi-equality, do generate a "bridge" equality between the first field inside SJM nest and the field that's first in the overall multi-equality.
2013-11-13 07:40:46 +04:00
# End of 5.5 tests
Change the default @@optimizer_switch setting from semijoin=on,firstmatch=on,loosescan=on to semijoin=off,firstmatch=off,loosescan=off Adjust the testcases: - Modify subselect*.test and join_cache.test so that all tests use the same execution paths as before (i.e. optimizations that are being tested are enabled) - Let all other test files run with the new default settings (i.e. with new optimizations disabled) - Copy subquery testcases from these files into t/subselect_extra.test which will run them with new optimizations enabled.
2011-07-05 01:44:15 +04:00
set @subselect_mat_test_optimizer_switch_value=null;
Post-merge fix for tests - bad .result merge - make .test file do not switch off both materialization and IN->EXISTS as that leads to error now.
2011-05-29 00:51:26 +04:00
set @@optimizer_switch='materialization=on,in_to_exists=off,semijoin=off';
Set the default to be mrr=off,mrr_sort_keys=off: - Set the default - Adjust the testcases so that 'new' tests are run with optimizations turned on. - Pull out relevant tests from "irrelevant" tests and run them with optimizations on. - Run range.test and innodb.test with both mrr=on and mrr=off
2011-07-08 18:46:47 +04:00
set optimizer_switch='mrr=on,mrr_sort_keys=on,index_condition_pushdown=on';
MWL#90: Subqueries: Inside-out execution for materialized non-sj subqueries - Merge with 5.3 (3)
2011-02-15 20:29:57 +03:00
create table t0 (a int);
insert into t0 values (0),(1),(2);
create table t1 (a int);
insert into t1 values (0),(1),(2);
explain select a, a in (select a from t1) from t0;
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t0 ALL NULL NULL NULL NULL 3
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t1 ALL NULL NULL NULL NULL 3
MWL#90: Subqueries: Inside-out execution for materialized non-sj subqueries - Merge with 5.3 (3)
2011-02-15 20:29:57 +03:00
select a, a in (select a from t1) from t0;
a a in (select a from t1)
0 1
1 1
2 1
prepare s from 'select a, a in (select a from t1) from t0';
execute s;
a a in (select a from t1)
0 1
1 1
2 1
update t1 set a=123;
execute s;
a a in (select a from t1)
0 0
1 0
2 0
drop table t0, t1;
Fixed LP bug #609121 The bug was a result of missing logic to handle the case when there are 'expensive' predicates that are not evaluated during constant table optimization. Such is the case for the IN predicate, which is considered expensive if it is computed via materialization. In general this bug can be triggered with any expensive predicate instead of IN. When FALSE constant predicates are not evaluated during constant optimization, the execution path changes so that instead of setting JOIN::zero_result_cause after make_join_select, and exiting JOIN::exec via the call to return_zero_rows(), execution ends in JOIN::exec in the branch: if (join->tables == join->const_tables) { ... else if (join->send_row_on_empty_set()) ... rc= join->result->send_data(*columns_list); } Unlike return_zero_rows(), this branch didn't evaluate the having clause of the query. The patch adds a call to evaluate the HAVING clause of a query even when all tables are constant, because even for an empty result set some aggregate functions may produce a NULL value.
2010-10-25 23:48:43 +03:00
#
# LPBUG#609121: RQG: wrong result on aggregate + NOT IN + HAVING and
# partial_match_table_scan=on
#
create table t1 (c1 int);
create table t2 (c2 int);
insert into t1 values (1);
insert into t2 values (2);
set @@optimizer_switch='semijoin=off';
EXPLAIN
SELECT SUM(c1) c1_sum FROM t1 WHERE c1 IN (SELECT c2 FROM t2);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 system NULL NULL NULL NULL 1
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 system NULL NULL NULL NULL 1
Fixed LP bug #609121 The bug was a result of missing logic to handle the case when there are 'expensive' predicates that are not evaluated during constant table optimization. Such is the case for the IN predicate, which is considered expensive if it is computed via materialization. In general this bug can be triggered with any expensive predicate instead of IN. When FALSE constant predicates are not evaluated during constant optimization, the execution path changes so that instead of setting JOIN::zero_result_cause after make_join_select, and exiting JOIN::exec via the call to return_zero_rows(), execution ends in JOIN::exec in the branch: if (join->tables == join->const_tables) { ... else if (join->send_row_on_empty_set()) ... rc= join->result->send_data(*columns_list); } Unlike return_zero_rows(), this branch didn't evaluate the having clause of the query. The patch adds a call to evaluate the HAVING clause of a query even when all tables are constant, because even for an empty result set some aggregate functions may produce a NULL value.
2010-10-25 23:48:43 +03:00
SELECT SUM(c1) c1_sum FROM t1 WHERE c1 IN (SELECT c2 FROM t2);
c1_sum
NULL
EXPLAIN
SELECT SUM(c1) c1_sum FROM t1 WHERE c1 IN (SELECT c2 FROM t2) HAVING c1_sum;
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 system NULL NULL NULL NULL 1
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 system NULL NULL NULL NULL 1
Fixed LP bug #609121 The bug was a result of missing logic to handle the case when there are 'expensive' predicates that are not evaluated during constant table optimization. Such is the case for the IN predicate, which is considered expensive if it is computed via materialization. In general this bug can be triggered with any expensive predicate instead of IN. When FALSE constant predicates are not evaluated during constant optimization, the execution path changes so that instead of setting JOIN::zero_result_cause after make_join_select, and exiting JOIN::exec via the call to return_zero_rows(), execution ends in JOIN::exec in the branch: if (join->tables == join->const_tables) { ... else if (join->send_row_on_empty_set()) ... rc= join->result->send_data(*columns_list); } Unlike return_zero_rows(), this branch didn't evaluate the having clause of the query. The patch adds a call to evaluate the HAVING clause of a query even when all tables are constant, because even for an empty result set some aggregate functions may produce a NULL value.
2010-10-25 23:48:43 +03:00
SELECT SUM(c1) c1_sum FROM t1 WHERE c1 IN (SELECT c2 FROM t2) HAVING c1_sum;
c1_sum
drop table t1, t2;
Fix LP BUG#611622 Fix MySQL BUG#52344 - Subquery materialization: Assertion if subquery in on-clause of outer join Original fix and comments from Oysten, adjusted for the different subquery optimization in MariaDB. " Problem: If tables of an outer join are constant tables, the associated on-clause will be evaluated in the optimization phase. If the on-clause contains a query that is to be executed with subquery materialization, this will not work since the infrastructure for such execution is not yet set up. Solution: Do not evaluate on-clause in optimization phase if is_expensive() returns true for this clause. This is how the problem is currently avoided for where-clauses. This works because, Item_in_subselect::is_expensive_processor returns true if query is to be executed with subquery materialization. " In addition, after MWL#89, in MariaDB if the IN-EXISTS strategy is chosen, the in-to-exists predicates are insterted after join_read_const_table() is called, resulting in evaluation of the subquery without the in-to-exists predicates.
2010-11-25 11:43:23 +02:00
#
# BUG#52344 - Subquery materialization:
# Assertion if subquery in on-clause of outer join
#
set @@optimizer_switch='semijoin=off';
CREATE TABLE t1 (i INTEGER);
INSERT INTO t1 VALUES (10);
CREATE TABLE t2 (j INTEGER);
INSERT INTO t2 VALUES (5);
CREATE TABLE t3 (k INTEGER);
EXPLAIN
SELECT i FROM t1 LEFT JOIN t2 ON (j) IN (SELECT k FROM t3);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 system NULL NULL NULL NULL 1
Fixed LP bug #813447. Do not make substitution of a single-row table if it is an inner table of an outer join with on expression containing an expensive subquery.
2011-07-21 00:43:37 -07:00
1 PRIMARY t2 ALL NULL NULL NULL NULL 1 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t3 system NULL NULL NULL NULL 0 const row not found
Fix LP BUG#611622 Fix MySQL BUG#52344 - Subquery materialization: Assertion if subquery in on-clause of outer join Original fix and comments from Oysten, adjusted for the different subquery optimization in MariaDB. " Problem: If tables of an outer join are constant tables, the associated on-clause will be evaluated in the optimization phase. If the on-clause contains a query that is to be executed with subquery materialization, this will not work since the infrastructure for such execution is not yet set up. Solution: Do not evaluate on-clause in optimization phase if is_expensive() returns true for this clause. This is how the problem is currently avoided for where-clauses. This works because, Item_in_subselect::is_expensive_processor returns true if query is to be executed with subquery materialization. " In addition, after MWL#89, in MariaDB if the IN-EXISTS strategy is chosen, the in-to-exists predicates are insterted after join_read_const_table() is called, resulting in evaluation of the subquery without the in-to-exists predicates.
2010-11-25 11:43:23 +02:00
SELECT i FROM t1 LEFT JOIN t2 ON (j) IN (SELECT k FROM t3);
i
10
EXPLAIN
SELECT i FROM t1 LEFT JOIN t2 ON (j) IN (SELECT max(k) FROM t3);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 system NULL NULL NULL NULL 1
Fixed LP bug #813447. Do not make substitution of a single-row table if it is an inner table of an outer join with on expression containing an expensive subquery.
2011-07-21 00:43:37 -07:00
1 PRIMARY t2 ALL NULL NULL NULL NULL 1 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t3 system NULL NULL NULL NULL 0 const row not found
Fix LP BUG#611622 Fix MySQL BUG#52344 - Subquery materialization: Assertion if subquery in on-clause of outer join Original fix and comments from Oysten, adjusted for the different subquery optimization in MariaDB. " Problem: If tables of an outer join are constant tables, the associated on-clause will be evaluated in the optimization phase. If the on-clause contains a query that is to be executed with subquery materialization, this will not work since the infrastructure for such execution is not yet set up. Solution: Do not evaluate on-clause in optimization phase if is_expensive() returns true for this clause. This is how the problem is currently avoided for where-clauses. This works because, Item_in_subselect::is_expensive_processor returns true if query is to be executed with subquery materialization. " In addition, after MWL#89, in MariaDB if the IN-EXISTS strategy is chosen, the in-to-exists predicates are insterted after join_read_const_table() is called, resulting in evaluation of the subquery without the in-to-exists predicates.
2010-11-25 11:43:23 +02:00
SELECT i FROM t1 LEFT JOIN t2 ON (j) IN (SELECT max(k) FROM t3);
i
10
DROP TABLE t1, t2, t3;
#
Merged the code of MWL#106 into 5.3 Resolved all conflicts, bad merges and fixed a few minor bugs in the code. Commented out the queries from multi_update, view, subselect_sj, func_str, derived_view, view_grant that failed either with crashes in ps-protocol or with wrong results. The failures are clear indications of some bugs in the code and these bugs are to be fixed.
2011-05-16 22:39:43 -07:00
# LPBUG#611622/BUG#52344: Subquery materialization: Assertion
# if subquery in on-clause of outer join
Fix LP BUG#611622 Fix MySQL BUG#52344 - Subquery materialization: Assertion if subquery in on-clause of outer join Original fix and comments from Oysten, adjusted for the different subquery optimization in MariaDB. " Problem: If tables of an outer join are constant tables, the associated on-clause will be evaluated in the optimization phase. If the on-clause contains a query that is to be executed with subquery materialization, this will not work since the infrastructure for such execution is not yet set up. Solution: Do not evaluate on-clause in optimization phase if is_expensive() returns true for this clause. This is how the problem is currently avoided for where-clauses. This works because, Item_in_subselect::is_expensive_processor returns true if query is to be executed with subquery materialization. " In addition, after MWL#89, in MariaDB if the IN-EXISTS strategy is chosen, the in-to-exists predicates are insterted after join_read_const_table() is called, resulting in evaluation of the subquery without the in-to-exists predicates.
2010-11-25 11:43:23 +02:00
#
CREATE TABLE t1 (c1 int);
INSERT INTO t1 VALUES (1),(2);
CREATE TABLE t2 (c2 int);
INSERT INTO t2 VALUES (10);
PREPARE st1 FROM "
SELECT *
Merged the code of MWL#106 into 5.3 Resolved all conflicts, bad merges and fixed a few minor bugs in the code. Commented out the queries from multi_update, view, subselect_sj, func_str, derived_view, view_grant that failed either with crashes in ps-protocol or with wrong results. The failures are clear indications of some bugs in the code and these bugs are to be fixed.
2011-05-16 22:39:43 -07:00
FROM t2 LEFT JOIN t2 t3 ON (8, 4) IN (SELECT c1, c1 FROM t1)";
Fix LP BUG#611622 Fix MySQL BUG#52344 - Subquery materialization: Assertion if subquery in on-clause of outer join Original fix and comments from Oysten, adjusted for the different subquery optimization in MariaDB. " Problem: If tables of an outer join are constant tables, the associated on-clause will be evaluated in the optimization phase. If the on-clause contains a query that is to be executed with subquery materialization, this will not work since the infrastructure for such execution is not yet set up. Solution: Do not evaluate on-clause in optimization phase if is_expensive() returns true for this clause. This is how the problem is currently avoided for where-clauses. This works because, Item_in_subselect::is_expensive_processor returns true if query is to be executed with subquery materialization. " In addition, after MWL#89, in MariaDB if the IN-EXISTS strategy is chosen, the in-to-exists predicates are insterted after join_read_const_table() is called, resulting in evaluation of the subquery without the in-to-exists predicates.
2010-11-25 11:43:23 +02:00
EXECUTE st1;
c2 c2
Fixed LP bug #813447. Do not make substitution of a single-row table if it is an inner table of an outer join with on expression containing an expensive subquery.
2011-07-21 00:43:37 -07:00
10 NULL
Fix LP BUG#611622 Fix MySQL BUG#52344 - Subquery materialization: Assertion if subquery in on-clause of outer join Original fix and comments from Oysten, adjusted for the different subquery optimization in MariaDB. " Problem: If tables of an outer join are constant tables, the associated on-clause will be evaluated in the optimization phase. If the on-clause contains a query that is to be executed with subquery materialization, this will not work since the infrastructure for such execution is not yet set up. Solution: Do not evaluate on-clause in optimization phase if is_expensive() returns true for this clause. This is how the problem is currently avoided for where-clauses. This works because, Item_in_subselect::is_expensive_processor returns true if query is to be executed with subquery materialization. " In addition, after MWL#89, in MariaDB if the IN-EXISTS strategy is chosen, the in-to-exists predicates are insterted after join_read_const_table() is called, resulting in evaluation of the subquery without the in-to-exists predicates.
2010-11-25 11:43:23 +02:00
EXECUTE st1;
c2 c2
Fixed LP bug #813447. Do not make substitution of a single-row table if it is an inner table of an outer join with on expression containing an expensive subquery.
2011-07-21 00:43:37 -07:00
10 NULL
Fix LP BUG#611622 Fix MySQL BUG#52344 - Subquery materialization: Assertion if subquery in on-clause of outer join Original fix and comments from Oysten, adjusted for the different subquery optimization in MariaDB. " Problem: If tables of an outer join are constant tables, the associated on-clause will be evaluated in the optimization phase. If the on-clause contains a query that is to be executed with subquery materialization, this will not work since the infrastructure for such execution is not yet set up. Solution: Do not evaluate on-clause in optimization phase if is_expensive() returns true for this clause. This is how the problem is currently avoided for where-clauses. This works because, Item_in_subselect::is_expensive_processor returns true if query is to be executed with subquery materialization. " In addition, after MWL#89, in MariaDB if the IN-EXISTS strategy is chosen, the in-to-exists predicates are insterted after join_read_const_table() is called, resulting in evaluation of the subquery without the in-to-exists predicates.
2010-11-25 11:43:23 +02:00
DROP TABLE t1, t2;
Testcase backport: BUG#46548 IN-subqueries return 0 rows with materialization=on (the bug itself was fixed during the subquery code backport)
2011-01-14 13:51:30 +03:00
#
# Testcase backport: BUG#46548 IN-subqueries return 0 rows with materialization=on
#
CREATE TABLE t1 (
pk int,
a varchar(1),
b varchar(4),
c varchar(4),
d varchar(4),
PRIMARY KEY (pk)
);
INSERT INTO t1 VALUES (1,'o','ffff','ffff','ffoo'),(2,'f','ffff','ffff','ffff');
CREATE TABLE t2 LIKE t1;
INSERT INTO t2 VALUES (1,'i','iiii','iiii','iiii'),(2,'f','ffff','ffff','ffff');
SET @@optimizer_switch='default,semijoin=on,materialization=on';
EXPLAIN SELECT pk FROM t1 WHERE (a) IN (SELECT a FROM t2 WHERE pk > 0);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 2
Fixed LP bug #939009. The result of materialization of the right part of an IN subquery predicate is placed into a temporary table. Each row of the materialized table is distinct. A unique key over all fields of the temporary table is defined and created. It allows to perform key look-ups into the table. The table created for a materialized subquery can be accessed by key as any other table. The function best_access-path search for the best access to join a table to a given partial join. With some where conditions this function considers a possibility of a ref_or_null access. If such access employs the unique key on the temporary table then when estimating the cost this access the function tries to use the array rec_per_key. Yet, such array is not built for this unique key. This causes a crash of the server. Rows returned by the subquery that contain nulls don't have to be placed into temporary table, as they cannot be match any row produced by the left part of the subquery predicate. So all fields of the temporary table can be defined as non-nullable. In this case any ref_or_null access to the temporary table does not make any sense and it does not make sense to estimate such an access. The fix makes sure that the temporary table for a materialized IN subquery is defined with columns that are all non-nullable. The also ensures that any row with nulls returned by the subquery is not placed into the temporary table.
2012-02-24 16:50:22 -08:00
1 PRIMARY <subquery2> eq_ref distinct_key distinct_key 4 func 1
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 range PRIMARY PRIMARY 4 NULL 2 Using index condition
Testcase backport: BUG#46548 IN-subqueries return 0 rows with materialization=on (the bug itself was fixed during the subquery code backport)
2011-01-14 13:51:30 +03:00
SELECT pk FROM t1 WHERE (a) IN (SELECT a FROM t2 WHERE pk > 0);
pk
2
SELECT pk FROM t1 WHERE (b,c,d) IN (SELECT b,c,d FROM t2 WHERE pk > 0);
pk
2
DROP TABLE t1, t2;
Fix LP BUG#719198, LP BUG#730604 Analysis (BUG#719198): The assert failed because the execution code for partial matching is designed with the assumption that NULLs on the left side are detected as early as possible, and a NULL result is returned before any lookups are performed at all. However, in the case of an Item_cache object on the left side, null was not detected properly, because detection was done via Item::is_null(), which is not implemented at all for Item_cache, and resolved to the default Item::is_null() which always returns FALSE. Solution: Imlpement Item::is_null(). ****** Analysis (BUG#730604): The method Item_field::is_null() determines if an item is NULL from its Item_field::field object. However, for Item_fields that represent internal temporary tables, Item_field::field represents the field of the original table that was the source for the temporary table (in this case t1.f3). Both in the committed test case, and in the original bug report the current value of t1.f3 is not NULL. This results in an incorrect count of NULLs for this column. As a consequence, all related Ordered_key buffers are allocated with incorrect sizes. Depending on the exact query and data, these incorrect sizes result in various crashes or failed asserts. Solution: The correct value of the current field of the internal temp table is in Item_field::result_field. This value is determined by Item::is_null_result().
2011-03-13 15:03:26 +00:00
#
BUG#724228: Wrong result with materialization=on and three aggregates in maria-5.3-mwl90 - In join buffering code, call join_tab_execution_startup() (#1) before we call join_tab_scan->open() (#2). This is important with SJ-Materialization because #1 fills the materialized table, while #2 will actually try to read the first row. Attempt to read the first row before we have populated the materialized table would cause zero rows to be returned when actually there were matches.
2011-03-01 12:01:10 +03:00
# BUG#724228: Wrong result with materialization=on and three aggregates in maria-5.3-mwl90
#
CREATE TABLE t1 ( f2 int(11)) ;
INSERT IGNORE INTO t1 VALUES ('7'),('9'),('7'),('4'),('2'),('6'),('8'),('5'),('6'),('188'),('2'),('1'),('1'),('0'),('9'),('4');
CREATE TABLE t2 ( f1 int(11), f2 int(11)) ENGINE=MyISAM;
INSERT IGNORE INTO t2 VALUES ('1','1');
CREATE TABLE t3 ( f1 int(11), f2 int(11), f3 int(11), PRIMARY KEY (f1)) ;
INSERT IGNORE INTO t3 VALUES ('16','6','1'),('18','3','4'),('19',NULL,'9'),('20','0','6'),('41','2','0'),('42','2','5'),('43','9','6'),('44','7','4'),('45','1','4'),('46','222','238'),('47','3','6'),('48','6','6'),('49',NULL,'1'),('50','5','1');
SET @_save_join_cache_level = @@join_cache_level;
SET @_save_optimizer_switch = @@optimizer_switch;
SET join_cache_level = 1;
SET optimizer_switch='materialization=on';
SELECT f1 FROM t3
WHERE
f1 NOT IN (SELECT MAX(f2) FROM t1) AND
f3 IN (SELECT MIN(f1) FROM t2) AND
f1 IN (SELECT COUNT(f2) FROM t1);
f1
16
SET @@join_cache_level = @_save_join_cache_level;
SET @@optimizer_switch = @_save_optimizer_switch;
drop table t1, t2, t3;
Merge MWL#90 with main 5.3 tree
2011-04-02 14:09:00 +04:00
#
Fix LP BUG#719198, LP BUG#730604 Analysis (BUG#719198): The assert failed because the execution code for partial matching is designed with the assumption that NULLs on the left side are detected as early as possible, and a NULL result is returned before any lookups are performed at all. However, in the case of an Item_cache object on the left side, null was not detected properly, because detection was done via Item::is_null(), which is not implemented at all for Item_cache, and resolved to the default Item::is_null() which always returns FALSE. Solution: Imlpement Item::is_null(). ****** Analysis (BUG#730604): The method Item_field::is_null() determines if an item is NULL from its Item_field::field object. However, for Item_fields that represent internal temporary tables, Item_field::field represents the field of the original table that was the source for the temporary table (in this case t1.f3). Both in the committed test case, and in the original bug report the current value of t1.f3 is not NULL. This results in an incorrect count of NULLs for this column. As a consequence, all related Ordered_key buffers are allocated with incorrect sizes. Depending on the exact query and data, these incorrect sizes result in various crashes or failed asserts. Solution: The correct value of the current field of the internal temp table is in Item_field::result_field. This value is determined by Item::is_null_result().
2011-03-13 15:03:26 +00:00
# LPBUG#719198 Ordered_key::cmp_key_with_search_key(rownum_t): Assertion `!compare_pred[i]->null_value'
# failed with subquery on both sides of NOT IN and materialization
#
CREATE TABLE t1 (f1a int, f1b int) ;
INSERT IGNORE INTO t1 VALUES (1,1),(2,2);
CREATE TABLE t2 ( f2 int);
INSERT IGNORE INTO t2 VALUES (3),(4);
CREATE TABLE t3 (f3a int, f3b int);
MWL#89 Merge 5.3 with 5.3-mwl89.
2011-03-30 10:10:59 +03:00
set @@optimizer_switch='materialization=on,partial_match_rowid_merge=on,partial_match_table_scan=off,in_to_exists=off';
Fix LP BUG#719198, LP BUG#730604 Analysis (BUG#719198): The assert failed because the execution code for partial matching is designed with the assumption that NULLs on the left side are detected as early as possible, and a NULL result is returned before any lookups are performed at all. However, in the case of an Item_cache object on the left side, null was not detected properly, because detection was done via Item::is_null(), which is not implemented at all for Item_cache, and resolved to the default Item::is_null() which always returns FALSE. Solution: Imlpement Item::is_null(). ****** Analysis (BUG#730604): The method Item_field::is_null() determines if an item is NULL from its Item_field::field object. However, for Item_fields that represent internal temporary tables, Item_field::field represents the field of the original table that was the source for the temporary table (in this case t1.f3). Both in the committed test case, and in the original bug report the current value of t1.f3 is not NULL. This results in an incorrect count of NULLs for this column. As a consequence, all related Ordered_key buffers are allocated with incorrect sizes. Depending on the exact query and data, these incorrect sizes result in various crashes or failed asserts. Solution: The correct value of the current field of the internal temp table is in Item_field::result_field. This value is determined by Item::is_null_result().
2011-03-13 15:03:26 +00:00
EXPLAIN
SELECT * FROM t2 WHERE (SELECT f3a FROM t3) NOT IN (SELECT f1a FROM t1);
id select_type table type possible_keys key key_len ref rows Extra
Merged the fix for bug lp:944706, mdev-193
2012-06-19 15:06:45 +03:00
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL Impossible WHERE
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
3 MATERIALIZED t1 ALL NULL NULL NULL NULL 2
Fix LP BUG#777597 Analysis: During optimization of the subquery, in the call chain: update_ref_and_keys -> add_key_fields -> merge_key_fields -> Item_direct_ref::is_null -> Item_cache::is_null The call to Item_cache::is_null() returns TRUE, which is wrong. This results in Item_null replacing the field 'f3' in the KEY_FIELD, then this Item_null is used for index access, producing a wrong result. The reason why Item_cache::is_null returns wrong result is that this Item_cache object is a cache of the left operand of IN, and was updated in Item_in_optimizer::val_int. In MWL#89 the latter method is called during the execution phase, which is after we optimize the subquery. Therefore during the optization phase the left operand cache of IN was not updated. Solution: Update the left operand cache during optimization if it is a constant. This bug fix also discoveres and fixes a wrong IF statement in convert_constant_item().
2011-05-13 18:37:28 +03:00
2 SUBQUERY NULL NULL NULL NULL NULL NULL NULL no matching row in const table
Fix LP BUG#719198, LP BUG#730604 Analysis (BUG#719198): The assert failed because the execution code for partial matching is designed with the assumption that NULLs on the left side are detected as early as possible, and a NULL result is returned before any lookups are performed at all. However, in the case of an Item_cache object on the left side, null was not detected properly, because detection was done via Item::is_null(), which is not implemented at all for Item_cache, and resolved to the default Item::is_null() which always returns FALSE. Solution: Imlpement Item::is_null(). ****** Analysis (BUG#730604): The method Item_field::is_null() determines if an item is NULL from its Item_field::field object. However, for Item_fields that represent internal temporary tables, Item_field::field represents the field of the original table that was the source for the temporary table (in this case t1.f3). Both in the committed test case, and in the original bug report the current value of t1.f3 is not NULL. This results in an incorrect count of NULLs for this column. As a consequence, all related Ordered_key buffers are allocated with incorrect sizes. Depending on the exact query and data, these incorrect sizes result in various crashes or failed asserts. Solution: The correct value of the current field of the internal temp table is in Item_field::result_field. This value is determined by Item::is_null_result().
2011-03-13 15:03:26 +00:00
SELECT * FROM t2 WHERE (SELECT f3a FROM t3) NOT IN (SELECT f1a FROM t1);
f2
EXPLAIN
MWL#89 - Auto-merge with 5.3 main. - Changed the test for LP BUG#719198 so that an two more queries were added, and removed a query that produces a wrong result due to an unrelated problem. The wrong result is submitted as a separate bug.
2011-04-01 15:42:59 +03:00
SELECT (SELECT f3a FROM t3) NOT IN (SELECT f1a FROM t1);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL No tables used
Patch for mdev-287: CHEAP SQ: A query with subquery in SELECT list, EXISTS, inner joins takes hundreds times longer Analysis: The fix for lp:944706 introduces early subquery optimization. While a subquery is being optimized some of its predicates may be removed. In the test case, the EXISTS subquery is constant, and is evaluated to TRUE. As a result the whole OR is TRUE, and thus the correlated condition "b = alias1.b" is optimized away. The subquery becomes non-correlated. The subquery cache is designed to work only for correlated subqueries. If constant subquery optimization is disallowed, then the constant subquery is not evaluated, the subquery remains correlated, and its execution is cached. As a result execution is fast. However, when the constant subquery was optimized away, it was neither cached by the subquery cache, nor it was cached by the internal subquery caching. The latter was due to the fact that the subquery still appeared as correlated to the subselect_XYZ_engine::exec methods, and they re-executed the subquery on each call to Item_subselect::exec. Solution: The solution is to update the correlated status of the subquery after it has been optimized. This status consists of: - st_select_lex::is_correlated - Item_subselect::is_correlated - SELECT_LEX::uncacheable - SELECT_LEX_UNIT::uncacheable The status is updated by st_select_lex::update_correlated_cache(), and its caller st_select_lex::optimize_unflattened_subqueries. The solution relies on the fact that the optimizer already called st_select_lex::update_used_tables() for each subquery. This allows to efficiently update the correlated status of each subquery without walking the whole subquery tree. Notice that his patch is an improvement over MySQL 5.6 and older, where subqueries are not pre-optimized, and the above analysis is not possible.
2012-05-30 00:18:53 +03:00
3 SUBQUERY t1 ALL NULL NULL NULL NULL 2 Using where
Fix LP BUG#777597 Analysis: During optimization of the subquery, in the call chain: update_ref_and_keys -> add_key_fields -> merge_key_fields -> Item_direct_ref::is_null -> Item_cache::is_null The call to Item_cache::is_null() returns TRUE, which is wrong. This results in Item_null replacing the field 'f3' in the KEY_FIELD, then this Item_null is used for index access, producing a wrong result. The reason why Item_cache::is_null returns wrong result is that this Item_cache object is a cache of the left operand of IN, and was updated in Item_in_optimizer::val_int. In MWL#89 the latter method is called during the execution phase, which is after we optimize the subquery. Therefore during the optization phase the left operand cache of IN was not updated. Solution: Update the left operand cache during optimization if it is a constant. This bug fix also discoveres and fixes a wrong IF statement in convert_constant_item().
2011-05-13 18:37:28 +03:00
2 SUBQUERY NULL NULL NULL NULL NULL NULL NULL no matching row in const table
MWL#89 - Auto-merge with 5.3 main. - Changed the test for LP BUG#719198 so that an two more queries were added, and removed a query that produces a wrong result due to an unrelated problem. The wrong result is submitted as a separate bug.
2011-04-01 15:42:59 +03:00
SELECT (SELECT f3a FROM t3) NOT IN (SELECT f1a FROM t1);
(SELECT f3a FROM t3) NOT IN (SELECT f1a FROM t1)
NULL
EXPLAIN
Fix LP BUG#719198, LP BUG#730604 Analysis (BUG#719198): The assert failed because the execution code for partial matching is designed with the assumption that NULLs on the left side are detected as early as possible, and a NULL result is returned before any lookups are performed at all. However, in the case of an Item_cache object on the left side, null was not detected properly, because detection was done via Item::is_null(), which is not implemented at all for Item_cache, and resolved to the default Item::is_null() which always returns FALSE. Solution: Imlpement Item::is_null(). ****** Analysis (BUG#730604): The method Item_field::is_null() determines if an item is NULL from its Item_field::field object. However, for Item_fields that represent internal temporary tables, Item_field::field represents the field of the original table that was the source for the temporary table (in this case t1.f3). Both in the committed test case, and in the original bug report the current value of t1.f3 is not NULL. This results in an incorrect count of NULLs for this column. As a consequence, all related Ordered_key buffers are allocated with incorrect sizes. Depending on the exact query and data, these incorrect sizes result in various crashes or failed asserts. Solution: The correct value of the current field of the internal temp table is in Item_field::result_field. This value is determined by Item::is_null_result().
2011-03-13 15:03:26 +00:00
SELECT * FROM t2 WHERE (SELECT f3a, f3b FROM t3) NOT IN (SELECT f1a, f1b FROM t1);
id select_type table type possible_keys key key_len ref rows Extra
MDEV-410: EXPLAIN shows type=range, while SHOW EXPLAIN and userstat show full table scan is used - Make Item_subselect::fix_fields() ignore UNCACHEABLE_EXPLAIN flag when deciding whether the subquery item should be marked as constant.
2012-07-25 20:41:48 +04:00
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL Impossible WHERE
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
3 MATERIALIZED t1 ALL NULL NULL NULL NULL 2
Fix LP BUG#777597 Analysis: During optimization of the subquery, in the call chain: update_ref_and_keys -> add_key_fields -> merge_key_fields -> Item_direct_ref::is_null -> Item_cache::is_null The call to Item_cache::is_null() returns TRUE, which is wrong. This results in Item_null replacing the field 'f3' in the KEY_FIELD, then this Item_null is used for index access, producing a wrong result. The reason why Item_cache::is_null returns wrong result is that this Item_cache object is a cache of the left operand of IN, and was updated in Item_in_optimizer::val_int. In MWL#89 the latter method is called during the execution phase, which is after we optimize the subquery. Therefore during the optization phase the left operand cache of IN was not updated. Solution: Update the left operand cache during optimization if it is a constant. This bug fix also discoveres and fixes a wrong IF statement in convert_constant_item().
2011-05-13 18:37:28 +03:00
2 SUBQUERY NULL NULL NULL NULL NULL NULL NULL no matching row in const table
Fix LP BUG#719198, LP BUG#730604 Analysis (BUG#719198): The assert failed because the execution code for partial matching is designed with the assumption that NULLs on the left side are detected as early as possible, and a NULL result is returned before any lookups are performed at all. However, in the case of an Item_cache object on the left side, null was not detected properly, because detection was done via Item::is_null(), which is not implemented at all for Item_cache, and resolved to the default Item::is_null() which always returns FALSE. Solution: Imlpement Item::is_null(). ****** Analysis (BUG#730604): The method Item_field::is_null() determines if an item is NULL from its Item_field::field object. However, for Item_fields that represent internal temporary tables, Item_field::field represents the field of the original table that was the source for the temporary table (in this case t1.f3). Both in the committed test case, and in the original bug report the current value of t1.f3 is not NULL. This results in an incorrect count of NULLs for this column. As a consequence, all related Ordered_key buffers are allocated with incorrect sizes. Depending on the exact query and data, these incorrect sizes result in various crashes or failed asserts. Solution: The correct value of the current field of the internal temp table is in Item_field::result_field. This value is determined by Item::is_null_result().
2011-03-13 15:03:26 +00:00
SELECT * FROM t2 WHERE (SELECT f3a, f3b FROM t3) NOT IN (SELECT f1a, f1b FROM t1);
f2
EXPLAIN
MWL#89 - Auto-merge with 5.3 main. - Changed the test for LP BUG#719198 so that an two more queries were added, and removed a query that produces a wrong result due to an unrelated problem. The wrong result is submitted as a separate bug.
2011-04-01 15:42:59 +03:00
SELECT (SELECT f3a, f3b FROM t3) NOT IN (SELECT f1a, f1b FROM t1);
Fix LP BUG#719198, LP BUG#730604 Analysis (BUG#719198): The assert failed because the execution code for partial matching is designed with the assumption that NULLs on the left side are detected as early as possible, and a NULL result is returned before any lookups are performed at all. However, in the case of an Item_cache object on the left side, null was not detected properly, because detection was done via Item::is_null(), which is not implemented at all for Item_cache, and resolved to the default Item::is_null() which always returns FALSE. Solution: Imlpement Item::is_null(). ****** Analysis (BUG#730604): The method Item_field::is_null() determines if an item is NULL from its Item_field::field object. However, for Item_fields that represent internal temporary tables, Item_field::field represents the field of the original table that was the source for the temporary table (in this case t1.f3). Both in the committed test case, and in the original bug report the current value of t1.f3 is not NULL. This results in an incorrect count of NULLs for this column. As a consequence, all related Ordered_key buffers are allocated with incorrect sizes. Depending on the exact query and data, these incorrect sizes result in various crashes or failed asserts. Solution: The correct value of the current field of the internal temp table is in Item_field::result_field. This value is determined by Item::is_null_result().
2011-03-13 15:03:26 +00:00
id select_type table type possible_keys key key_len ref rows Extra
MWL#89 - Auto-merge with 5.3 main. - Changed the test for LP BUG#719198 so that an two more queries were added, and removed a query that produces a wrong result due to an unrelated problem. The wrong result is submitted as a separate bug.
2011-04-01 15:42:59 +03:00
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL No tables used
Patch for mdev-287: CHEAP SQ: A query with subquery in SELECT list, EXISTS, inner joins takes hundreds times longer Analysis: The fix for lp:944706 introduces early subquery optimization. While a subquery is being optimized some of its predicates may be removed. In the test case, the EXISTS subquery is constant, and is evaluated to TRUE. As a result the whole OR is TRUE, and thus the correlated condition "b = alias1.b" is optimized away. The subquery becomes non-correlated. The subquery cache is designed to work only for correlated subqueries. If constant subquery optimization is disallowed, then the constant subquery is not evaluated, the subquery remains correlated, and its execution is cached. As a result execution is fast. However, when the constant subquery was optimized away, it was neither cached by the subquery cache, nor it was cached by the internal subquery caching. The latter was due to the fact that the subquery still appeared as correlated to the subselect_XYZ_engine::exec methods, and they re-executed the subquery on each call to Item_subselect::exec. Solution: The solution is to update the correlated status of the subquery after it has been optimized. This status consists of: - st_select_lex::is_correlated - Item_subselect::is_correlated - SELECT_LEX::uncacheable - SELECT_LEX_UNIT::uncacheable The status is updated by st_select_lex::update_correlated_cache(), and its caller st_select_lex::optimize_unflattened_subqueries. The solution relies on the fact that the optimizer already called st_select_lex::update_used_tables() for each subquery. This allows to efficiently update the correlated status of each subquery without walking the whole subquery tree. Notice that his patch is an improvement over MySQL 5.6 and older, where subqueries are not pre-optimized, and the above analysis is not possible.
2012-05-30 00:18:53 +03:00
3 SUBQUERY t1 ALL NULL NULL NULL NULL 2 Using where
Fix LP BUG#777597 Analysis: During optimization of the subquery, in the call chain: update_ref_and_keys -> add_key_fields -> merge_key_fields -> Item_direct_ref::is_null -> Item_cache::is_null The call to Item_cache::is_null() returns TRUE, which is wrong. This results in Item_null replacing the field 'f3' in the KEY_FIELD, then this Item_null is used for index access, producing a wrong result. The reason why Item_cache::is_null returns wrong result is that this Item_cache object is a cache of the left operand of IN, and was updated in Item_in_optimizer::val_int. In MWL#89 the latter method is called during the execution phase, which is after we optimize the subquery. Therefore during the optization phase the left operand cache of IN was not updated. Solution: Update the left operand cache during optimization if it is a constant. This bug fix also discoveres and fixes a wrong IF statement in convert_constant_item().
2011-05-13 18:37:28 +03:00
2 SUBQUERY NULL NULL NULL NULL NULL NULL NULL no matching row in const table
MWL#89 - Auto-merge with 5.3 main. - Changed the test for LP BUG#719198 so that an two more queries were added, and removed a query that produces a wrong result due to an unrelated problem. The wrong result is submitted as a separate bug.
2011-04-01 15:42:59 +03:00
SELECT (SELECT f3a, f3b FROM t3) NOT IN (SELECT f1a, f1b FROM t1);
(SELECT f3a, f3b FROM t3) NOT IN (SELECT f1a, f1b FROM t1)
NULL
Fix LP BUG#719198, LP BUG#730604 Analysis (BUG#719198): The assert failed because the execution code for partial matching is designed with the assumption that NULLs on the left side are detected as early as possible, and a NULL result is returned before any lookups are performed at all. However, in the case of an Item_cache object on the left side, null was not detected properly, because detection was done via Item::is_null(), which is not implemented at all for Item_cache, and resolved to the default Item::is_null() which always returns FALSE. Solution: Imlpement Item::is_null(). ****** Analysis (BUG#730604): The method Item_field::is_null() determines if an item is NULL from its Item_field::field object. However, for Item_fields that represent internal temporary tables, Item_field::field represents the field of the original table that was the source for the temporary table (in this case t1.f3). Both in the committed test case, and in the original bug report the current value of t1.f3 is not NULL. This results in an incorrect count of NULLs for this column. As a consequence, all related Ordered_key buffers are allocated with incorrect sizes. Depending on the exact query and data, these incorrect sizes result in various crashes or failed asserts. Solution: The correct value of the current field of the internal temp table is in Item_field::result_field. This value is determined by Item::is_null_result().
2011-03-13 15:03:26 +00:00
drop table t1, t2, t3;
#
# LPBUG#730604 Assertion `bit < (map)->n_bits' failed in maria-5.3 with
# partial_match_rowid_merge
#
CREATE TABLE t1 (f1 int NOT NULL, f2 int, f3 int) ;
CREATE TABLE t2 (f1 int NOT NULL, f2 int, f3 int) ;
INSERT INTO t1 VALUES (60, 3, null), (61, null, 77);
INSERT INTO t2 VALUES (1000,6,2);
MWL#89 Merge 5.3 with 5.3-mwl89.
2011-03-30 10:10:59 +03:00
set @@optimizer_switch='materialization=on,partial_match_rowid_merge=on,partial_match_table_scan=off,in_to_exists=off';
Fix LP BUG#719198, LP BUG#730604 Analysis (BUG#719198): The assert failed because the execution code for partial matching is designed with the assumption that NULLs on the left side are detected as early as possible, and a NULL result is returned before any lookups are performed at all. However, in the case of an Item_cache object on the left side, null was not detected properly, because detection was done via Item::is_null(), which is not implemented at all for Item_cache, and resolved to the default Item::is_null() which always returns FALSE. Solution: Imlpement Item::is_null(). ****** Analysis (BUG#730604): The method Item_field::is_null() determines if an item is NULL from its Item_field::field object. However, for Item_fields that represent internal temporary tables, Item_field::field represents the field of the original table that was the source for the temporary table (in this case t1.f3). Both in the committed test case, and in the original bug report the current value of t1.f3 is not NULL. This results in an incorrect count of NULLs for this column. As a consequence, all related Ordered_key buffers are allocated with incorrect sizes. Depending on the exact query and data, these incorrect sizes result in various crashes or failed asserts. Solution: The correct value of the current field of the internal temp table is in Item_field::result_field. This value is determined by Item::is_null_result().
2011-03-13 15:03:26 +00:00
EXPLAIN
SELECT (f1, f2, f3) NOT IN
(SELECT COUNT(DISTINCT f2), f1, f3 FROM t1 GROUP BY f1, f3)
FROM t2;
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t2 system NULL NULL NULL NULL 1
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t1 ALL NULL NULL NULL NULL 2 Using filesort
Fix LP BUG#719198, LP BUG#730604 Analysis (BUG#719198): The assert failed because the execution code for partial matching is designed with the assumption that NULLs on the left side are detected as early as possible, and a NULL result is returned before any lookups are performed at all. However, in the case of an Item_cache object on the left side, null was not detected properly, because detection was done via Item::is_null(), which is not implemented at all for Item_cache, and resolved to the default Item::is_null() which always returns FALSE. Solution: Imlpement Item::is_null(). ****** Analysis (BUG#730604): The method Item_field::is_null() determines if an item is NULL from its Item_field::field object. However, for Item_fields that represent internal temporary tables, Item_field::field represents the field of the original table that was the source for the temporary table (in this case t1.f3). Both in the committed test case, and in the original bug report the current value of t1.f3 is not NULL. This results in an incorrect count of NULLs for this column. As a consequence, all related Ordered_key buffers are allocated with incorrect sizes. Depending on the exact query and data, these incorrect sizes result in various crashes or failed asserts. Solution: The correct value of the current field of the internal temp table is in Item_field::result_field. This value is determined by Item::is_null_result().
2011-03-13 15:03:26 +00:00
SELECT (f1, f2, f3) NOT IN
(SELECT COUNT(DISTINCT f2), f1, f3 FROM t1 GROUP BY f1, f3)
FROM t2;
(f1, f2, f3) NOT IN
(SELECT COUNT(DISTINCT f2), f1, f3 FROM t1 GROUP BY f1, f3)
1
drop table t1, t2;
Fixed LP bug #702301. The function matching_cond should take into account that there may be always false constant conjunctive conditions that has not been evaluated yet,for example, conjunctive conditions with non-correlated subqueries.
2011-07-20 16:09:28 -07:00
#
# LPBUG#702301: MAX in select + always false WHERE with SQ
#
CREATE TABLE t1 (a int, b int, KEY (b));
INSERT INTO t1 VALUES (3,1), (4,2);
CREATE TABLE t2 (a int);
INSERT INTO t2 VALUES (7), (8);
set @@optimizer_switch='materialization=on,in_to_exists=off,semijoin=off';
SELECT MAX(t1.b) AS max_res FROM t1 WHERE (9) IN (SELECT a FROM t2);
max_res
NULL
EXPLAIN EXTENDED
SELECT MAX(t1.b) AS max_res FROM t1 WHERE (9) IN (SELECT a FROM t2);
id select_type table type possible_keys key key_len ref rows filtered Extra
Fix for bug lp:944706, task MDEV-193 The patch enables back constant subquery execution during query optimization after it was disabled during the development of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION). The main idea is that constant subqueries are allowed to be executed during optimization if their execution is not expensive. The approach is as follows: - Constant subqueries are recursively optimized in the beginning of JOIN::optimize of the outer query. This is done by the new method JOIN::optimize_constant_subqueries(). This is done so that the cost of executing these queries can be estimated. - Optimization of the outer query proceeds normally. During this phase the optimizer may request execution of non-expensive constant subqueries. Each place where the optimizer may potentially execute an expensive expression is guarded with the predicate Item::is_expensive(). - The implementation of Item_subselect::is_expensive has been extended to use the number of examined rows (estimated by the optimizer) as a way to determine whether the subquery is expensive or not. - The new system variable "expensive_subquery_limit" controls how many examined rows are considered to be not expensive. The default is 100. In addition, multiple changes were needed to make this solution work in the light of the changes made by MWL#89. These changes were needed to fix various crashes and wrong results, and legacy bugs discovered during development.
2012-05-17 13:46:05 +03:00
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL NULL Impossible WHERE
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 2 100.00
Fixed LP bug #702301. The function matching_cond should take into account that there may be always false constant conjunctive conditions that has not been evaluated yet,for example, conjunctive conditions with non-correlated subqueries.
2011-07-20 16:09:28 -07:00
Warnings:
Fix for bug lp:944706, task MDEV-193 The patch enables back constant subquery execution during query optimization after it was disabled during the development of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION). The main idea is that constant subqueries are allowed to be executed during optimization if their execution is not expensive. The approach is as follows: - Constant subqueries are recursively optimized in the beginning of JOIN::optimize of the outer query. This is done by the new method JOIN::optimize_constant_subqueries(). This is done so that the cost of executing these queries can be estimated. - Optimization of the outer query proceeds normally. During this phase the optimizer may request execution of non-expensive constant subqueries. Each place where the optimizer may potentially execute an expensive expression is guarded with the predicate Item::is_expensive(). - The implementation of Item_subselect::is_expensive has been extended to use the number of examined rows (estimated by the optimizer) as a way to determine whether the subquery is expensive or not. - The new system variable "expensive_subquery_limit" controls how many examined rows are considered to be not expensive. The default is 100. In addition, multiple changes were needed to make this solution work in the light of the changes made by MWL#89. These changes were needed to fix various crashes and wrong results, and legacy bugs discovered during development.
2012-05-17 13:46:05 +03:00
Note 1003 select max(`test`.`t1`.`b`) AS `max_res` from `test`.`t1` where 0
Fixed LP bug #702301. The function matching_cond should take into account that there may be always false constant conjunctive conditions that has not been evaluated yet,for example, conjunctive conditions with non-correlated subqueries.
2011-07-20 16:09:28 -07:00
set @@optimizer_switch='materialization=off,in_to_exists=on,semijoin=off';
SELECT MAX(t1.b) AS max_res FROM t1 WHERE (9) IN (SELECT a FROM t2);
max_res
NULL
EXPLAIN EXTENDED
SELECT MAX(t1.b) AS max_res FROM t1 WHERE (9) IN (SELECT a FROM t2);
id select_type table type possible_keys key key_len ref rows filtered Extra
Fix for bug lp:944706, task MDEV-193 The patch enables back constant subquery execution during query optimization after it was disabled during the development of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION). The main idea is that constant subqueries are allowed to be executed during optimization if their execution is not expensive. The approach is as follows: - Constant subqueries are recursively optimized in the beginning of JOIN::optimize of the outer query. This is done by the new method JOIN::optimize_constant_subqueries(). This is done so that the cost of executing these queries can be estimated. - Optimization of the outer query proceeds normally. During this phase the optimizer may request execution of non-expensive constant subqueries. Each place where the optimizer may potentially execute an expensive expression is guarded with the predicate Item::is_expensive(). - The implementation of Item_subselect::is_expensive has been extended to use the number of examined rows (estimated by the optimizer) as a way to determine whether the subquery is expensive or not. - The new system variable "expensive_subquery_limit" controls how many examined rows are considered to be not expensive. The default is 100. In addition, multiple changes were needed to make this solution work in the light of the changes made by MWL#89. These changes were needed to fix various crashes and wrong results, and legacy bugs discovered during development.
2012-05-17 13:46:05 +03:00
1 PRIMARY NULL NULL NULL NULL NULL NULL NULL NULL Impossible WHERE
Fixed bug lp:1000649 Analysis: When the method JOIN::choose_subquery_plan() decided to apply the IN-TO-EXISTS strategy, it set the unit and select_lex uncacheable flag to UNCACHEABLE_DEPENDENT_INJECTED unconditionally. As result, even if IN-TO-EXISTS injected non-correlated predicates, the subquery was still treated as correlated. Solution: Set the subquery as correlated only if the injected predicate(s) depend on the outer query.
2012-06-05 17:25:10 +03:00
2 SUBQUERY t2 ALL NULL NULL NULL NULL 2 100.00 Using where
Fixed LP bug #702301. The function matching_cond should take into account that there may be always false constant conjunctive conditions that has not been evaluated yet,for example, conjunctive conditions with non-correlated subqueries.
2011-07-20 16:09:28 -07:00
Warnings:
Fix for bug lp:944706, task MDEV-193 The patch enables back constant subquery execution during query optimization after it was disabled during the development of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION). The main idea is that constant subqueries are allowed to be executed during optimization if their execution is not expensive. The approach is as follows: - Constant subqueries are recursively optimized in the beginning of JOIN::optimize of the outer query. This is done by the new method JOIN::optimize_constant_subqueries(). This is done so that the cost of executing these queries can be estimated. - Optimization of the outer query proceeds normally. During this phase the optimizer may request execution of non-expensive constant subqueries. Each place where the optimizer may potentially execute an expensive expression is guarded with the predicate Item::is_expensive(). - The implementation of Item_subselect::is_expensive has been extended to use the number of examined rows (estimated by the optimizer) as a way to determine whether the subquery is expensive or not. - The new system variable "expensive_subquery_limit" controls how many examined rows are considered to be not expensive. The default is 100. In addition, multiple changes were needed to make this solution work in the light of the changes made by MWL#89. These changes were needed to fix various crashes and wrong results, and legacy bugs discovered during development.
2012-05-17 13:46:05 +03:00
Note 1003 select max(`test`.`t1`.`b`) AS `max_res` from `test`.`t1` where 0
Fixed LP bug #702301. The function matching_cond should take into account that there may be always false constant conjunctive conditions that has not been evaluated yet,for example, conjunctive conditions with non-correlated subqueries.
2011-07-20 16:09:28 -07:00
DROP TABLE t1,t2;
Fix bug lp:825095 Analysis: Partial matching is used even when there are no NULLs in a materialized subquery, as long as the left NOT IN operand may contain NULL values. This case was not handled correctly in two different places. First, the implementation of parital matching did not clear the set of matching columns when the merge process advanced to the next row. Second, there is no need to perform partial matching at all when the left operand has no NULLs. Solution: First fix subselect_rowid_merge_engine::partial_match() to properly cleanup the bitmap of matching keys when advancing to the next row. Second, change subselect_partial_match_engine::exec() so that when the materialized subquery doesn't contain any NULLs, and the left operand of [NOT] IN doesn't contain NULLs either, the method returns without doing any unnecessary partial matching. The correct result in this case is in Item::in_value.
2011-08-23 00:00:13 +03:00
#
# LPBUG#825095: Wrong result with materialization and NOT IN with 2 expressions
#
CREATE TABLE t1 (a int,b int);
INSERT INTO t1 VALUES (4,4),(4,2);
CREATE TABLE t2 (b int, a int);
INSERT INTO t2 VALUES (4,3),(8,4);
set @@optimizer_switch='semijoin=off,in_to_exists=off,materialization=on,partial_match_rowid_merge=on,partial_match_table_scan=off';
EXPLAIN SELECT *
FROM t1
WHERE (a, b) NOT IN (SELECT a, b FROM t2);
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 2 Using where
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 2
Fix bug lp:825095 Analysis: Partial matching is used even when there are no NULLs in a materialized subquery, as long as the left NOT IN operand may contain NULL values. This case was not handled correctly in two different places. First, the implementation of parital matching did not clear the set of matching columns when the merge process advanced to the next row. Second, there is no need to perform partial matching at all when the left operand has no NULLs. Solution: First fix subselect_rowid_merge_engine::partial_match() to properly cleanup the bitmap of matching keys when advancing to the next row. Second, change subselect_partial_match_engine::exec() so that when the materialized subquery doesn't contain any NULLs, and the left operand of [NOT] IN doesn't contain NULLs either, the method returns without doing any unnecessary partial matching. The correct result in this case is in Item::in_value.
2011-08-23 00:00:13 +03:00
SELECT *
FROM t1
WHERE (a, b) NOT IN (SELECT a, b FROM t2);
a b
4 4
4 2
EXPLAIN
SELECT a, b, (a, b) NOT IN (SELECT a, b FROM t2) as sq
FROM t1;
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t1 ALL NULL NULL NULL NULL 2
Make subquery Materialization, as well as semi-join Materialization be shown in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
2011-12-05 01:31:42 +04:00
2 MATERIALIZED t2 ALL NULL NULL NULL NULL 2
Fix bug lp:825095 Analysis: Partial matching is used even when there are no NULLs in a materialized subquery, as long as the left NOT IN operand may contain NULL values. This case was not handled correctly in two different places. First, the implementation of parital matching did not clear the set of matching columns when the merge process advanced to the next row. Second, there is no need to perform partial matching at all when the left operand has no NULLs. Solution: First fix subselect_rowid_merge_engine::partial_match() to properly cleanup the bitmap of matching keys when advancing to the next row. Second, change subselect_partial_match_engine::exec() so that when the materialized subquery doesn't contain any NULLs, and the left operand of [NOT] IN doesn't contain NULLs either, the method returns without doing any unnecessary partial matching. The correct result in this case is in Item::in_value.
2011-08-23 00:00:13 +03:00
SELECT a, b, (a, b) NOT IN (SELECT a, b FROM t2) as sq
FROM t1;
a b sq
4 4 1
4 2 1
drop table t1, t2;
MDEV-15235: Assertion `length > 0' failed in create_ref_for_key The issue is that we are creating a materialised table with key of length 0 which is incorrect, we should disable materialisation for such a case.
2018-03-06 19:59:57 +05:30
#
# MDEV-15235: Assertion `length > 0' failed in create_ref_for_key
#
CREATE TABLE t1 (i INT);
INSERT INTO t1 VALUES (1),(2);
CREATE TABLE t2 (f CHAR(1));
INSERT INTO t2 VALUES ('a'),('b');
explain
SELECT * FROM t2 WHERE f IN ( SELECT LEFT('foo',0) FROM t1 ORDER BY 1 );
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY t2 ALL NULL NULL NULL NULL 2 Using where
2 DEPENDENT SUBQUERY t1 ALL NULL NULL NULL NULL 2
SELECT * FROM t2 WHERE f IN ( SELECT LEFT('foo',0) FROM t1 ORDER BY 1 );
f
DROP TABLE t1, t2;
Reference in a new issue Copy permalink