Details
-
Bug
-
Status: Open (View Workflow)
-
Blocker
-
Resolution: Unresolved
-
12.3, 13.0, 13.1, 13.2
Description
--source include/have_partition.inc
|
--source include/have_sequence.inc
|
 |
CREATE TABLE t1 (x INT, y INT); |
INSERT INTO t1 VALUES (5,25); |
CREATE TABLE t2 (a INT, b INT, KEY(a)) PARTITION BY RANGE (a) (PARTITION p0 VALUES LESS THAN (10), PARTITION p1 VALUES LESS THAN (20), PARTITION p2 VALUES LESS THAN MAXVALUE); |
INSERT INTO t2 SELECT seq, seq FROM seq_1_to_3000; |
ANALYZE TABLE t1, t2 PERSISTENT FOR ALL; |
--connect (con1,localhost,root,,test)
|
--send SELECT t2.a FROM t1, t2 WHERE t2.a = t1.x OR t2.a = t1.y
|
--connection default
|
--sleep 5
|
--let $c= query_get_value(SELECT COUNT(*) AS c FROM information_schema.PROCESSLIST WHERE INFO LIKE 'SELECT t2.a FROM t1%', c, 1)
|
if ($c) |
{
|
--die The join never finishes: the range scan on t2 loops on partition p1, which has no range to read |
}
|
--connection con1
|
--reap
|
--disconnect con1
|
--connection default
|
DROP TABLE t1, t2; |
Leads to:
|
CS 13.1.2 87e62ca17270e163a6d41b3fc8d6f4d440f1bb88 (Optimized, Clang 22.1.8-20260622) Build 06/10/2026 |
mysqltest: At line 16: The join never finishes: the range scan on t2 loops on partition p1, which has no range to read
|
The join runs at 100% CPU, and KILL leaves it in state Killed, still running. Debug builds hang in the same way. So does the same join on InnoDB, where the plan is "Range checked for each record", and a BKA join (join_cache_level=6, mrr=on) whose outer keys map to p0 and p2 only. CS 11.8.9 returns the rows 5 and 25.
From the code it seems that ha_partition::multi_range_read_init() marks in m_mrr_used_partitions only the partitions that an exact range maps to. Pruning cannot use t1.x and t1.y, so p1 stays in read_partitions without a range. ha_partition::handle_unordered_scan_next_partition() skips such a partition with continue, but its loop moves to the next partition only at the end of the loop body, so the scan stays on p1.
Attachments
Issue Links
- is caused by
-
MDEV-37330 Ordered scans over PARTITION BY RANGE should not use priority queue
-
- Closed
-