MDEV-35291 derived_with_keys not applied for UNION with const filter#5188
MDEV-35291 derived_with_keys not applied for UNION with const filter#5188DaveGosselin-MariaDB wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Code Review
This pull request updates several test result files to reflect optimizer plan improvements, specifically replacing full table scans with index lookups (ref on key0) or hash joins using constant keys, and adds a test case for MDEV-35291. However, a critical correctness regression was identified in subselect3_jcl6.result, where a query result row was lost. This issue is likely caused by an incomplete port of the optimization, and further investigation is required to ensure correctness.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
The optimizer fails to generate a derived key when a materialized
UNION derived table is filtered by a constant equality, as in:
SELECT dt.* FROM
((SELECT * FROM t1 LIMIT 100) UNION
(SELECT * FROM t1 LIMIT 200)) dt
WHERE id = 1;
The condition cannot be pushed into the underlying SELECTs because
LIMIT inside each branch blocks pushdown, so the only remaining
optimization is to build a derived key on id and access via
ref(const). But add_key_part() registers KEYUSE entries for the
materialized derived only when the value side of the equality
references another table. That excludes constants, leaving the
outer query no choice but to scan the full materialized result.
Investigation showed that this is the same defect that Rex Johnston
already fixed under MDEV-39499 (see the bb-11.4-MDEV-39499 branch).
This commit ports the add_key_part() change from MDEV-39499 to 10.11.
0beba62 to
4e91aeb
Compare
The optimizer fails to generate a derived key when a materialized UNION derived table is filtered by a constant equality, as in:
The condition cannot be pushed into the underlying SELECTs because LIMIT inside each branch blocks pushdown, so the only remaining optimization is to build a derived key on id and access via ref(const). But add_key_part() registers KEYUSE entries for the materialized derived only when the value side of the equality references another table. That excludes constants, leaving the outer query no choice but to scan the full materialized result.
Investigation showed that this is the same defect that Rex Johnston already fixed under MDEV-39499 (see the bb-11.4-MDEV-39499 branch).
This commit ports the add_key_part() change from MDEV-39499 to 10.11. It does not port the rest of Rex's commit because it depends on KEY::rec_per_key_null_aware() and the KEY::all_nulls_key_parts bitmap populated by the rewritten sql_statistics code, neither of which exists in 10.11. But it turns out that doesn't matter for this bug and the add_key_part() is sufficient to fix it.