Bug#54444: Do not run main.range test for products without partitioning

feature

The test for bug no 50939 was put in range.test which isn't such a good idea
since it requires partitioning. Fixed by moving the test case to
partitioning_range.test.

1 files changed, 0 insertions, 44 deletions

diff --git a/mysql-test/r/range.result b/mysql-test/r/range.result
index ad8aec7383a..64e00521cd2 100644
--- a/mysql-test/r/range.result
+++ b/mysql-test/r/range.result
@@ -1653,48 +1653,4 @@ a	b
 0	0
 1	1
 DROP TABLE t1;
-#
-# Bug#50939: Loose Index Scan unduly relies on engine to remember range 
-# endpoints
-#
-CREATE TABLE t1 (
-a INT,
-b INT,
-KEY ( a, b )
-) PARTITION BY HASH (a) PARTITIONS 1;
-CREATE TABLE t2 (
-a INT,
-b INT,
-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;
-INSERT INTO t1 SELECT a + 10, b + 10 FROM t1;
-INSERT INTO t1 SELECT a + 20, b + 20 FROM t1;
-INSERT INTO t1 SELECT a + 40, b + 40 FROM t1;
-INSERT INTO t2 SELECT * FROM t1;
-# plans should be identical
-EXPLAIN SELECT a, MAX(b) FROM t1 WHERE a IN (10,100) GROUP BY a;
-id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
-1	SIMPLE	t1	range	a	a	5	NULL	1	Using where; Using index for group-by
-EXPLAIN SELECT a, MAX(b) FROM t2 WHERE a IN (10,100) GROUP BY a;
-id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
-1	SIMPLE	t2	range	a	a	5	NULL	2	Using where; Using index for group-by
-FLUSH status;
-SELECT a, MAX(b) FROM t1 WHERE a IN (10, 100) GROUP BY a;
-a	MAX(b)
-10	10
-# Should be no more than 4 reads.
-SHOW status LIKE 'handler_read_key';
-Variable_name	Value
-Handler_read_key	4
-FLUSH status;
-SELECT a, MAX(b) FROM t2 WHERE a IN (10, 100) GROUP BY a;
-a	MAX(b)
-10	10
-# Should be no more than 4 reads.
-SHOW status LIKE 'handler_read_key';
-Variable_name	Value
-Handler_read_key	4
-DROP TABLE t1, t2;
 End of 5.1 tests