Details
-
Bug
-
Status: In Progress (View Workflow)
-
Critical
-
Resolution: Unresolved
-
10.6
-
Q3/2025 Maintenance
Description
DELETE derived table query taking very long to execute on 10.6 CS version whereas same query was running fast enough on 10.2 CS.
Workaround:
set optimizer_switch='split_materialized=off'; |
Table definition:
CREATE TABLE `COMPLETED_TXN_COMP
|
` (
|
`TEST_TXNID` bigint(20) NOT NULL, |
`TEST_DATABASE` varchar(128) NOT NULL, |
`TEST_TABLE` varchar(256) DEFAULT NULL, |
`TEST_PARTITION` varchar(767) DEFAULT NULL, |
`TEST_TIMESTAMP` timestamp NOT NULL DEFAULT current_timestamp(),
|
`TEST_WRITEID` bigint(20) DEFAULT NULL, |
`TEST_UPDATE_DELETE` char(1) NOT NULL, |
KEY `COMPLETED_TXN_COMP_idx` (`TEST_DATABASE`,`TEST_TABLE`,`TEST_PARTITION`) USING BTREE
|
) ENGINE=InnoDB DEFAULT CHARSET=latin1
|
All other relevant info is attached including explain, optimizer_trace output etc.
Attachments
Issue Links
- includes
-
MDEV-37050 Lousy join order without EITS
-
- In Progress
-
-
MDEV-37057 Wrong result with LATERAL DERIVED
-
- Stalled
-
- relates to
-
MDEV-16057 Using optimization Splitting with Group BY we see an unnecessary attached condition t1.pk IS NOT NULL where pk is a PRIMARY KEY
-
- Closed
-
-
MDEV-37044 derived_with_keys optimization not applied where it should
-
- In Progress
-
-
MDEV-37181 ref_or_null optimizer depends on the order of conditions in WHERE
-
- Open
-