mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-20 14:02:32 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/t/subselect_sj2_mat.test

306 lines
9.6 KiB
Text
Raw Normal View History

MWL#89 Adjusted test cases in accordance with the implementation.
2011-02-03 16:00:28 +01:00
#
# Run subselect_sj2.test with subquery materialization.
#
set optimizer_switch='materialization=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 16:46:47 +02:00
set optimizer_switch='mrr=on,mrr_sort_keys=on,index_condition_pushdown=on';
MWL#89 Adjusted test cases in accordance with the implementation.
2011-02-03 16:00:28 +01:00
--source t/subselect_sj2.test
set optimizer_switch=default;
select @@optimizer_switch like '%materialization=on%';
BUG#906385: EXPLAIN EXTENDED crashes in TABLE_LIST::print with limited max_join_size - Take into account that subquery's optimization can fail because of @@max_join_size error.
2011-12-19 19:24:10 +01:00
--echo #
--echo # BUG#906385: EXPLAIN EXTENDED crashes in TABLE_LIST::print with limited max_join_size
--echo #
CREATE TABLE t1 ( a INT );
CREATE TABLE t2 ( b INT );
INSERT INTO t1 VALUES (1),(2);
INSERT INTO t2 VALUES
(1),(2),(3),(4),(5),
(6),(7),(8),(9),(10),
(11),(12),(13),(14),(15),
(16),(17),(18),(19),(20);
set @tmp_906385=@@max_join_size;
SET max_join_size = 80;
--error ER_TOO_BIG_SELECT
EXPLAIN EXTENDED
SELECT COUNT(*) FROM t1
WHERE a IN
( SELECT b FROM t2 GROUP BY b )
AND ( 6 ) IN
( SELECT MIN( t2.b ) FROM t2 alias1, t2 );
DROP TABLE t1, t2;
set max_join_size= @tmp_906385;
Fixed bug mdev-3995. This bug happened because the executor tried to use a wrong TABLE REF object when building access keys. It constructed keys from fields of a materialized table from a ref object created to construct keys from the fields of the underlying base table. This could happen only when materialized table was created for a non-correlated IN subquery and only when the materialized table used for lookups. In this case we are guaranteed to be able to construct the keys from the fields of tables that would be outer tables for the tables of the IN subquery. The patch makes sure that no ref objects constructed from fields of materialized lookup tables are to be used.
2013-02-08 06:46:02 +01:00
--echo #
--echo # mdev-3995: Wrong result for semijoin with materialization
--echo #
set @save_optimizer_switch=@@optimizer_switch;
CREATE TABLE t1 (
cat_id int(10) unsigned NOT NULL,
PRIMARY KEY (cat_id)
) ENGINE=MyISAM;
INSERT INTO t1 VALUES
(709411),(709412),(709413),(709414),(709416),(709417),(709418),(709419),(709421),(709422),
(709424),(709425),(709427),(709428),(709429),(709431),(709432),(709433),(709434),(709435),
(709438),(709439),(709441),(709442),(709443),(709444),(709445),(709446),(709447),(709450),
(709451),(709454),(709455),(709456),(709457),(709459),(709460),(709461),(709462),(709463),
(709464),(709465),(709467),(709469),(709470),(709471),(709472),(709473),(709474),(709475),
(709476),(709477),(709478),(709479),(709480),(709481),(709483),(709484),(709485),(709487),
(709490),(709491),(709492),(709493),(709494),(709495),(709496),(709497),(709498),(709499),
(709500),(709501),(709502),(709503),(709504),(709505),(709506),(709507),(709509),(709510),
(709511),(709512),(709513),(709514),(709515),(709516),(709517),(709518),(709519),(709520),
(709521),(709522),(709523),(709524),(709525),(709526),(709527),(709528),(709529),(709530),
(709531),(709532),(709533),(709534),(709535),(709536),(709537),(709538),(709539),(709540),
(709541),(709542),(709543),(709544),(709545),(709546),(709548),(709549),(709551),(709552),
(709553),(709555),(709556),(709557),(709558),(709559),(709560),(709561),(709562),(709563),
(709564),(709565),(709566),(709567),(709568),(709569),(709570),(709571),(709572),(709573),
(709574),(709575),(709576),(709577),(709578),(709579),(709580),(709581),(709582),(709583),
(709584),(709585),(709586),(709587),(709588),(709590),(709591),(709592),(709593),(709594),
(709595),(709596),(709597),(709598),(709600),(709601),(709602),(709603),(709604),(709605),
(709606),(709608),(709609),(709610),(709611),(709612),(709613),(709614),(709615),(709616),
(709617),(709618),(709619),(709620),(709621),(709622),(709623),(709624),(709625),(709626),
(709627),(709628),(709629),(709630),(709631),(709632),(709633),(709634),(709635),(709637),
(709638),(709639),(709640),(709641),(709642),(709643),(709644),(709645),(709646),(709649),
(709650),(709651),(709652),(709653),(709654),(709655),(709656),(709657),(709658),(709659);
CREATE TABLE t2 (
cat_id int(10) NOT NULL,
KEY cat_id (cat_id)
) ENGINE=MyISAM;
INSERT INTO t2 VALUES
(708742),(708755),(708759),(708761),(708766),(708769),(708796),(708798),(708824),(708825),
(708838),(708844),(708861),(708882),(708887),(708889),(708890),(709586),(709626);
CREATE TABLE t3 (
sack_id int(10) unsigned NOT NULL,
kit_id tinyint(3) unsigned NOT NULL DEFAULT '0',
cat_id int(10) unsigned NOT NULL,
PRIMARY KEY (sack_id,kit_id,cat_id)
) ENGINE=MyISAM;
INSERT INTO t3 VALUES
(33479,6,708523),(33479,6,708632),(33479,6,709085),(33479,6,709586),(33479,6,709626);
CREATE TABLE t4 (
cat_id int(10) unsigned NOT NULL,
KEY cat_id (cat_id)
) ENGINE=MyISAM;
INSERT INTO t4 (cat_id) SELECT cat_id from t2;
set optimizer_switch='materialization=off';
EXPLAIN
SELECT count(*) FROM t1, t3
WHERE t1.cat_id = t3.cat_id AND
t3.cat_id IN (SELECT cat_id FROM t2) AND
t3.sack_id = 33479 AND t3.kit_id = 6;
SELECT count(*) FROM t1, t3
WHERE t1.cat_id = t3.cat_id AND
t3.cat_id IN (SELECT cat_id FROM t2) AND
t3.sack_id = 33479 AND t3.kit_id = 6;
set optimizer_switch='materialization=on';
EXPLAIN
SELECT count(*) FROM t1, t3
WHERE t1.cat_id = t3.cat_id AND
t3.cat_id IN (SELECT cat_id FROM t4) AND
t3.sack_id = 33479 AND t3.kit_id = 6;
SELECT count(*) FROM t1, t3
WHERE t1.cat_id = t3.cat_id AND
t3.cat_id IN (SELECT cat_id FROM t4) AND
t3.sack_id = 33479 AND t3.kit_id = 6;
EXPLAIN
SELECT count(*) FROM t1, t3
WHERE t1.cat_id = t3.cat_id AND
t3.cat_id IN (SELECT cat_id FROM t2) AND
t3.sack_id = 33479 AND t3.kit_id = 6;
SELECT count(*) FROM t1, t3
WHERE t1.cat_id = t3.cat_id AND
t3.cat_id IN (SELECT cat_id FROM t2) AND
t3.sack_id = 33479 AND t3.kit_id = 6;
DROP TABLE t1,t2,t3,t4;
set optimizer_switch=@save_optimizer_switch;
Merge.
2013-02-21 04:22:02 +01:00
Fixed bug mdev-3913. The wrong result set returned by the left join query from the bug test case happened due to several inconsistencies and bugs of the legacy mysql code. The bug test case uses an execution plan that employs a scan of a materialized IN subquery from the WHERE condition. When materializing such an IN- subquery the optimizer injects additional equalities into the WHERE clause. These equalities express the constraints imposed by the subquery predicate. The injected equality of the query in the test case happens to belong to the same equality class, and a new equality imposing a condition on the rows of the materialized subquery is inferred from this class. Simultaneously the multiple equality is added to the ON expression of the LEFT JOIN used in the main query. The inferred equality of the form f1=f2 is taken into account when optimizing the scan of the rows the temporary table that is the result of the subquery materialization: only the values of the field f1 are read from the table into the record buffer. Meanwhile the inferred equality is removed from the WHERE conditions altogether as a constraint on the fields of the temporary table that has been used when filling this table. This equality is supposed to be removed from the ON expression when the multiple equalities of the ON expression are converted into an optimal set of equality predicates. It supposed to be removed from the ON expression as an equality inferred from only equalities of the WHERE condition. Yet, it did not happened due to the following bug in the code. Erroneously the code tried to build multiple equality for ON expression twice: the first time, when it called optimize_cond() for the WHERE condition, the second time, when it called this function for the HAVING condition. When executing optimize_con() for the WHERE condition a reference to the multiple equality of the WHERE condition is set in the multiple equality of the ON expression. This reference would allow later to convert multiple equalities of the ON expression into equality predicates. However the the second call of build_equal_items() for the ON expression that happened when optimize_cond() was called for the HAVING condition reset this reference to NULL. This bug fix blocks calling build_equal_items() for ON expressions for the second time. In general, it will be beneficial for many queries as it removes from ON expressions any equalities that are to be checked for the WHERE condition. The patch also fixes two bugs in the list manipulation operations and a bug in the function substitute_for_best_equal_field() that resulted in passing wrong reference to the multiple equalities of where conditions when processing multiple equalities of ON expressions. The code of substitute_for_best_equal_field() and the code the helper function eliminate_item_equal() were also streamlined and cleaned up. Now the conversion of the multiple equalities into an optimal set of equality predicates first produces the sequence of the all equalities processing multiple equalities one by one, and, only after this, it inserts the equalities at the beginning of the other conditions. The multiple changes in the output of EXPLAIN EXTENDED are mainly the result of this streamlining, but in some cases is the result of the removal of unneeded equalities from ON expressions. In some test cases this removal were reflected in the output of EXPLAIN resulted in disappearance of “Using where” in some rows of the execution plans.
2013-02-21 03:01:36 +01:00
--echo #
--echo # mdev-3913: LEFT JOIN with materialized multi-table IN subquery in WHERE
--echo #
set @save_optimizer_switch=@@optimizer_switch;
CREATE TABLE t1 (a1 char(1), b1 char(1), index idx(b1,a1));
INSERT INTO t1 VALUES ('f','c'),('d','m'),('g','y');
INSERT INTO t1 VALUES ('f','c'),('d','m'),('g','y');
CREATE TABLE t2 (a2 char(1), b2 char(1));
INSERT INTO t2 VALUES ('y','y'),('y','y'),('w','w');
CREATE TABLE t3 (a3 int);
INSERT INTO t3 VALUES (8),(6);
CREATE TABLE t4 (a4 char(1), b4 char(1));
INSERT INTO t4 VALUES ('y','y'),('y','y'),('w','w');
set optimizer_switch='materialization=off';
EXPLAIN EXTENDED
SELECT * FROM t1 LEFT JOIN t2 ON ( b1 = a2 )
WHERE ( b1, b1 ) IN ( SELECT a4, b4 FROM t3, t4);
SELECT * FROM t1 LEFT JOIN t2 ON ( b1 = a2 )
WHERE ( b1, b1 ) IN ( SELECT a4, b4 FROM t3, t4);
set optimizer_switch='materialization=on';
EXPLAIN EXTENDED
SELECT * FROM t1 LEFT JOIN t2 ON ( b1 = a2 )
WHERE ( b1, b1 ) IN ( SELECT a4, b4 FROM t3, t4);
SELECT * FROM t1 LEFT JOIN t2 ON ( b1 = a2 )
WHERE ( b1, b1 ) IN ( SELECT a4, b4 FROM t3, t4);
DROP TABLE t1,t2,t3,t4;
set optimizer_switch=@save_optimizer_switch;
Fixed bug mdev-4172. This bug in the legacy code could manifest itself in queries with semi-join materialized subqueries. When a subquery is materialized all conditions that are imposed only on the columns belonging to the tables from the subquery are taken into account.The code responsible for subquery optimizations that employes subquery materialization makes sure to remove these conditions from the WHERE conditions of the query obtained after it has transformed the original query into a query with a semi-join. If the condition to be removed is an equality condition it could be added to ON expressions and/or conditions from disjunctive branches (parts of OR conditions) in an attempt to generate better access keys to the tables of the query. Such equalities are supposed to be removed later from all the formulas where they have been added to. However, erroneously, this was not done in some cases when an ON expression and/or a disjunctive part of the OR condition could be converted into one multiple equality. As a result some equality predicates over columns belonging to the tables of the materialized subquery remained in the ON condition and/or the a disjunctive part of the OR condition, and the excuter later, when trying to evaluate them, returned wrong answers as the values of the fields from these equalities were not valid. This happened because any standalone multiple equality (a multiple equality that are not ANDed with any other predicates) lacked the information about equality predicates inherited from upper levels (in particular, inherited from the WHERE condition). The fix adds a reference to such information to any standalone multiple equality.
2013-02-22 02:13:12 +01:00
--echo #
--echo # mdev-4172: LEFT JOIN with materialized multi-table IN subquery in WHERE
--echo # and OR in ON condition
--echo #
set @save_optimizer_switch=@@optimizer_switch;
CREATE TABLE t1 (a1 int, c1 varchar(1));
INSERT t1 VALUES (7,'v'), (3,'y');
CREATE TABLE t2 (c2 varchar(1));
INSERT INTO t2 VALUES ('y'), ('y');
CREATE TABLE t3 (c3 varchar(1));
INSERT INTO t3 VALUES
('j'), ('v'), ('c'), ('m'), ('d'),
('d'), ('y'), ('t'), ('d'), ('s');
CREATE TABLE t4 (a4 int, c4 varchar(1));
INSERT INTO t4 SELECT * FROM t1;
set optimizer_switch='materialization=off';
EXPLAIN EXTENDED
SELECT * FROM t1 LEFT JOIN t2 ON (c2 = c1 OR c1 > 'z')
WHERE c1 IN ( SELECT c4 FROM t3,t4 WHERE c3 = c4);
SELECT * FROM t1 LEFT JOIN t2 ON (c2 = c1 OR c1 > 'z')
WHERE c1 IN ( SELECT c4 FROM t3,t4 WHERE c3 = c4);
set optimizer_switch='materialization=on';
EXPLAIN EXTENDED
SELECT * FROM t1 LEFT JOIN t2 ON (c2 = c1 OR c1 > 'z')
WHERE c1 IN ( SELECT c4 FROM t3,t4 WHERE c3 = c4);
SELECT * FROM t1 LEFT JOIN t2 ON (c2 = c1 OR c1 > 'z')
WHERE c1 IN ( SELECT c4 FROM t3,t4 WHERE c3 = c4);
DROP TABLE t1,t2,t3,t4;
set optimizer_switch=@save_optimizer_switch;
Fixed bug mdev-4177 The function remove_eq_cond removes the parts of a disjunction for which it has been proved that they are always true. In the result of this removal the disjunction may be converted into a formula without OR that must be merged into the the AND formula that contains the disjunction. The merging of two AND conditions must take into account the multiple equalities that may be part of each of them. These multiple equality must be merged and become part of the and object built as the result of the merge of the AND conditions. Erroneously the function remove_eq_cond lacked the code that would merge multiple equalities of the merged AND conditions. This could lead to confusing situations when at the same AND level there were two multiple equalities with common members and the list of equal items contained only some of these multiple equalities. This, in its turn, could lead to an incorrect work of the function substitute_for_best_equal_field when it tried to optimize ref accesses. This resulted in forming invalid TABLE_REF objects that were used to build look-up keys when materialized subqueries were exploited.
2013-02-25 04:16:11 +01:00
--echo #
--echo # mdev-4177: materialization of a subquery whose WHERE condition is OR
--echo # formula with two disjucts such that the second one is always false
--echo #
set @save_optimizer_switch=@@optimizer_switch;
set @save_join_cache_level=@@join_cache_level;
CREATE TABLE t1 (i1 int) ENGINE=MyISAM;
INSERT INTO t1 VALUES (1), (7), (4), (8), (4);
CREATE TABLE t2 (i2 int) ENGINE=MyISAM;
INSERT INTO t2 VALUES (7), (5);
CREATE TABLE t3 (i3 int) ENGINE=MyISAM;
INSERT INTO t3 VALUES (7), (2), (9);
set join_cache_level=3;
set optimizer_switch='materialization=off,semijoin=off';
EXPLAIN EXTENDED
SELECT * FROM t1 WHERE i1 IN (SELECT i3 FROM t2, t3 WHERE i3 = i2 OR 1=2);
SELECT * FROM t1 WHERE i1 IN (SELECT i3 FROM t2, t3 WHERE i3 = i2 OR 1=2);
set optimizer_switch='materialization=on,semijoin=on';
EXPLAIN EXTENDED
SELECT * FROM t1 WHERE i1 IN (SELECT i3 FROM t2, t3 WHERE i3 = i2 OR 1=2);
SELECT * FROM t1 WHERE i1 IN (SELECT i3 FROM t2, t3 WHERE i3 = i2 OR 1=2);
EXPLAIN EXTENDED
SELECT * FROM t1
WHERE i1 IN (SELECT i3 FROM t2, t3 WHERE i3 > 0 AND i3 = i2 OR 1=2);
SELECT * FROM t1
WHERE i1 IN (SELECT i3 FROM t2, t3 WHERE i3 > 0 AND i3 = i2 OR 1=2);
SELECT * FROM t1
WHERE i1 IN (SELECT i3 FROM t2, t3 WHERE i3 > 7 AND i3 = i2 OR 1=2);
DROP TABLE t1,t2,t3;
set join_cache_level= @save_join_cache_level;
set optimizer_switch=@save_optimizer_switch;
Fixed the bug mdev-7791. When an IN subquery predicate was converted to a semi-join that were materialized and the result of the materialization happened to be the last in the execution plan then any conjunctive condition with RAND() turned out to be lost. Fixed by attaching this condition to the last top base table.
2017-05-16 17:24:42 +02:00
--echo #
--echo # mdev-7791: materialization of a semi-join subquery +
--echo # RAND() in WHERE
--echo # (materialized table is accessed last)
--echo #
set @save_optimizer_switch=@@optimizer_switch;
set optimizer_switch='materialization=on';
create table t1(i int);
insert into t1 values (1), (2), (3), (7), (9), (10);
create table t2(i int);
insert into t2 values (1), (2), (3), (4), (5), (6), (7), (8), (9), (10);
select * from t1 where (rand() < 0) and i in (select i from t2);
explain extended
select * from t1 where (rand() < 0) and i in (select i from t2);
drop table t1,t2;
set optimizer_switch=@save_optimizer_switch;
Fixed the bug mdev-12855. This is actually a legacy bug: SQL_SELECT::test_quick_select() was called with SQL_SELECT::head not set. It looks like that this problem can be reproduced only on queries with ORDER BY that use IN predicates converted to semi-joins.
2017-06-08 07:54:57 +02:00
--echo #
--echo # mdev-12855: materialization of a semi-join subquery + ORDER BY
--echo #
CREATE TABLE t1 (f1 varchar(8), KEY(f1)) ENGINE=InnoDB;
INSERT INTO t1 VALUES ('qux'),('foo');
CREATE TABLE t2 (f2 varchar(8)) ENGINE=InnoDB;
INSERT INTO t2 VALUES ('bar'),('foo'),('qux');
let $q=
SELECT f1 FROM t1
WHERE f1 IN ( SELECT f2 FROM t2 WHERE f2 > 'bar' )
HAVING f1 != 'foo'
ORDER BY f1;
eval $q;
eval explain $q;
DROP TABLE t1,t2;
Reference in a new issue Copy permalink