Skip to content

MDEV-35291 derived_with_keys not applied for UNION with const filter#5188

Open
DaveGosselin-MariaDB wants to merge 1 commit into
10.11from
10.11-MDEV-35291-derived-with-keys
Open

MDEV-35291 derived_with_keys not applied for UNION with const filter#5188
DaveGosselin-MariaDB wants to merge 1 commit into
10.11from
10.11-MDEV-35291-derived-with-keys

Conversation

@DaveGosselin-MariaDB
Copy link
Copy Markdown
Member

@DaveGosselin-MariaDB DaveGosselin-MariaDB commented Jun 5, 2026

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. 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.

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread mysql-test/main/subselect3_jcl6.result Outdated
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.
@DaveGosselin-MariaDB DaveGosselin-MariaDB force-pushed the 10.11-MDEV-35291-derived-with-keys branch from 0beba62 to 4e91aeb Compare June 5, 2026 18:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

1 participant