Commit c09489eb authored by Martin Hansson's avatar Martin Hansson

Merge of fix for Bug#50394.

parents 83c5552b 20bdf763
...@@ -1617,6 +1617,27 @@ id select_type table type possible_keys key key_len ref rows Extra ...@@ -1617,6 +1617,27 @@ id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 range a a 5 NULL 2 Using where; Using temporary; Using filesort 1 SIMPLE t1 range a a 5 NULL 2 Using where; Using temporary; Using filesort
1 SIMPLE t2 ALL NULL NULL NULL NULL 10 Using join buffer 1 SIMPLE t2 ALL NULL NULL NULL NULL 10 Using join buffer
DROP TABLE t1, t2; DROP TABLE t1, t2;
#
# Bug #50394: Regression in EXPLAIN with index scan, LIMIT, GROUP BY and
# ORDER BY computed col
#
CREATE TABLE t1 ( a INT NOT NULL, b INT NOT NULL, KEY( a, b ) );
INSERT INTO t1 VALUES (1, 1), (2, 2), (3, 3), (4, 4), (5, 5);
INSERT INTO t1 SELECT a + 5, b + 5 FROM t1;
CREATE TABLE t2( a INT PRIMARY KEY, b INT );
INSERT INTO t2 VALUES (1, 1), (2, 2), (3, 3), (4, 4), (5, 5);
INSERT INTO t2 SELECT a + 5, b + 5 FROM t2;
EXPLAIN
SELECT count(*) AS c, t1.a
FROM t1 JOIN t2 ON t1.b = t2.a
WHERE t2.b = 1
GROUP BY t1.a
ORDER by c
LIMIT 2;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE t1 index NULL a 8 NULL 10 Using index; Using temporary; Using filesort
1 SIMPLE t2 eq_ref PRIMARY PRIMARY 4 test.t1.b 1 Using where
DROP TABLE t1, t2;
End of 5.1 tests End of 5.1 tests
# #
# Bug #38745: MySQL 5.1 optimizer uses filesort for ORDER BY # Bug #38745: MySQL 5.1 optimizer uses filesort for ORDER BY
......
...@@ -1467,6 +1467,31 @@ SELECT * FROM t1 FORCE INDEX FOR JOIN (a), t2 WHERE t1.a < 2 ORDER BY t1.a; ...@@ -1467,6 +1467,31 @@ SELECT * FROM t1 FORCE INDEX FOR JOIN (a), t2 WHERE t1.a < 2 ORDER BY t1.a;
DROP TABLE t1, t2; DROP TABLE t1, t2;
--echo #
--echo # Bug #50394: Regression in EXPLAIN with index scan, LIMIT, GROUP BY and
--echo # ORDER BY computed col
--echo #
CREATE TABLE t1 ( a INT NOT NULL, b INT NOT NULL, KEY( a, b ) );
INSERT INTO t1 VALUES (1, 1), (2, 2), (3, 3), (4, 4), (5, 5);
INSERT INTO t1 SELECT a + 5, b + 5 FROM t1;
CREATE TABLE t2( a INT PRIMARY KEY, b INT );
INSERT INTO t2 VALUES (1, 1), (2, 2), (3, 3), (4, 4), (5, 5);
INSERT INTO t2 SELECT a + 5, b + 5 FROM t2;
EXPLAIN
SELECT count(*) AS c, t1.a
FROM t1 JOIN t2 ON t1.b = t2.a
WHERE t2.b = 1
GROUP BY t1.a
ORDER by c
LIMIT 2;
DROP TABLE t1, t2;
--echo End of 5.1 tests --echo End of 5.1 tests
......
...@@ -1522,6 +1522,15 @@ JOIN::optimize() ...@@ -1522,6 +1522,15 @@ JOIN::optimize()
} }
if (order) if (order)
{ {
/*
Do we need a temporary table due to the ORDER BY not being equal to
the GROUP BY? The call to test_if_skip_sort_order above tests for the
GROUP BY clause only and hence is not valid in this case. So the
estimated number of rows to be read from the first table is not valid.
We clear it here so that it doesn't show up in EXPLAIN.
*/
if (need_tmp && (select_options & SELECT_DESCRIBE) != 0)
join_tab[const_tables].limit= 0;
/* /*
Force using of tmp table if sorting by a SP or UDF function due to Force using of tmp table if sorting by a SP or UDF function due to
their expensive and probably non-deterministic nature. their expensive and probably non-deterministic nature.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment