Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
Description
Currently, single-table UPDATE/DELETE statements cannot take advantage of semi-join optimizations. This is because semi-join optimizations are parts of join optimization (which is not invoked for single-table UPDATE/DELETE).
This task is about
- detecting UPDATE/DELETEs that can use semi-join optimizations
- switching those queries to be processed as multi-table UPDATE/DELETEs. This will enable semi-join optimizations.
Note that we do similar things for VIEWs: UPDATE multi_table_view SET =... is switched to be processed as multi-table UPDATE as soon as the server discovers that we're updating a multi-table VIEW.
Attachments
Issue Links
- causes
-
MDEV-33533 Crash at execution of DELETE when trying to use rowid filter
-
- Closed
-
-
MDEV-34113 Spider XA: ERROR 1440 (XAE08): XAER_DUPID: The XID already exists
-
- Confirmed
-
- duplicates
-
MDEV-15385 Full scan instead of index lookup on single table DELETE ... WHERE IN (SELECT ...)
-
- Closed
-
- is duplicated by
-
MDEV-15385 Full scan instead of index lookup on single table DELETE ... WHERE IN (SELECT ...)
-
- Closed
-
- is part of
-
MDEV-29547 prepare 10.11.0 preview releases
-
- Closed
-
- relates to
-
MDEV-22415 Single table UPDATE/DELETE doesn't use non-semijoin Materialization
-
- Closed
-
-
MDEV-10447 different execution plan for single- and multi-DELETE
-
- Open
-
-
MDEV-14956 Slow deletes if number of deleted rows smaller then LIMIT
-
- Closed
-
-
MDEV-18561 Semi-Join optimization for single-table update
-
- Closed
-
Activity
Transition | Time In Source Status | Execution Times |
---|
|
2693d 14h 26m | 1 |
|
13d 1h 16m | 1 |
|
9h 13m | 1 |
|
15h 58m | 1 |
|
97d 9h 48m | 1 |
|
141d 1h 50m | 1 |
|
30d 2h 1m | 1 |