Details
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.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
See also
MDEV-7220for a related discussion. Non-semijoin optimizations (e.g. Materialization vs IN->EXISTS) would are not used in single-table UPDATE/DELETE, either. And that is a deficiency, too.