Bug#41660: Sort-index_merge for non-first join table may

require O(#scans) memory

When an index merge operation was restarted, it would
re-allocate the Unique object controlling the duplicate row
ID elimination. Fixed by making the Unique object a member
of QUICK_INDEX_MERGE_SELECT and thus reusing it throughout
the lifetime of this object.

1 files changed, 35 insertions, 0 deletions

diff --git a/mysql-test/r/error_simulation.result b/mysql-test/r/error_simulation.result
index fc58687cc86..b6b79cb596b 100644
--- a/mysql-test/r/error_simulation.result
+++ b/mysql-test/r/error_simulation.result
@@ -48,5 +48,40 @@ Got one of the listed errors
 SET SESSION debug=DEFAULT;
 DROP TABLE t1;
 #
+# Bug#41660: Sort-index_merge for non-first join table may require 
+# O(#scans) memory
+#
+CREATE TABLE t1 (a INT);
+INSERT INTO t1 VALUES (0), (1), (2), (3), (4), (5), (6), (7), (8), (9);
+CREATE TABLE t2 (a INT, b INT, filler CHAR(100), KEY(a), KEY(b));
+INSERT INTO t2 SELECT 1000, 1000, 'filler' FROM t1 A, t1 B, t1 C;
+INSERT INTO t2 VALUES (1, 1, 'data');
+# the example query uses LEFT JOIN only for the sake of being able to
+# demonstrate the issue with a very small dataset. (left outer join 
+# disables the use of join buffering, so we get the second table 
+# re-scanned for every record in the outer table. if we used inner join,
+# we would need to have thousands of records and/or more columns in both
+# tables so that the join buffer is filled and re-scans are triggered).
+SET SESSION debug = '+d,only_one_Unique_may_be_created';
+EXPLAIN
+SELECT * FROM t1 LEFT JOIN t2 ON ( t2.a < 10 OR t2.b < 10 );
+id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
+x	x	x	x	x	x	x	x	x	
+x	x	x	x	x	x	x	x	x	Using sort_union(a,b); Using where
+SELECT * FROM t1 LEFT JOIN t2 ON ( t2.a < 10 OR t2.b < 10 );
+a	a	b	filler
+0	1	1	data
+1	1	1	data
+2	1	1	data
+3	1	1	data
+4	1	1	data
+5	1	1	data
+6	1	1	data
+7	1	1	data
+8	1	1	data
+9	1	1	data
+SET SESSION debug = DEFAULT;
+DROP TABLE t1, t2;
+#
 # End of 5.1 tests
 #