Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL)
-
Windows Server
Description
We used 10.2.x for a long time, where update commands on a partition were quite fast.
The third partition archive is very large and should not be part of the update. MariaDB 10.6.x uses all partitions on UPDATE, not on SELECT.
Simple Test |
USE test;
|
DROP TABLE IF EXISTS src;
|
DROP TABLE IF EXISTS trg;
|
|
CREATE TABLE src (
|
part INT(1), a INT(1),
|
b INT(1),
|
PRIMARY KEY (a,part),
|
INDEX b (b,part)
|
)ENGINE=InnoDB
|
PARTITION BY LIST (part) (
|
PARTITION Current VALUES IN (0),
|
PARTITION Relevant VALUES IN (1),
|
PARTITION Archive VALUES IN (2)
|
);
|
|
CREATE TABLE trg LIKE src;
|
INSERT INTO src (part,a,b) VALUES (0,0,0),(1,1,1),(2,2,2);
|
INSERT INTO trg (part,a,b) VALUES (0,0,0),(1,1,1),(2,2,2);
|
|
EXPLAIN FORMAT=JSON
|
UPDATE trg JOIN src USING(a) SET trg.part=1
|
WHERE trg.part=1 AND src.part=2 ;
|
Attachments
Issue Links
- relates to
-
MDEV-22248 Optimizer chooses wrong strategy on delete
- Closed
-
MDEV-22537 optimizer_use_cond_selectivity > 1 can cause slow plans
- Closed
-
MDEV-25480 Optimizer uses wrong index
- Stalled