Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.6, 10.3(EOL), 10.4(EOL), 10.5(EOL), 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
-
- Closed
-