Skip to content

MDEV-36610 Subquery wrongly marked as eliminated by table elimination#5384

Open
mariadb-RexJohnston wants to merge 1 commit into
10.11from
10.11-MDEV-36610
Open

MDEV-36610 Subquery wrongly marked as eliminated by table elimination#5384
mariadb-RexJohnston wants to merge 1 commit into
10.11from
10.11-MDEV-36610

Conversation

@mariadb-RexJohnston

Copy link
Copy Markdown
Member
When equality propagation (build_equal_items()) merges an equality that
contains a subquery, such as "t1.a = (SELECT ...)", with an outer join's
ON equality, it can inject a reference to that subquery into the ON
expression. If the join columns have compatible types the subquery ends
up as the constant of a multiple equality (which Item::walk() skips); if
they differ (e.g. BIGINT vs INT) the field cannot be merged and the
subquery is substituted in as a plain "tbl.col = (SELECT ...)" argument.

In the latter case, if that outer join is removed by table elimination,
mark_as_eliminated() walks the ON expression and flags the shared
Item_subselect as eliminated. The subquery, however, still lives in
another part of the query and has to be executed, tripping
DBUG_ASSERT(!eliminated) in Item_subselect::exec() (and, in release
builds, disabling the subquery cache and hiding it from EXPLAIN).

The surviving reference can be:
 - a WHERE/HAVING/select-list/ORDER/GROUP expression (subquery written
   there and pushed down into the eliminated ON), or
 - the ON expression of an outer join that was not eliminated (subquery
   written in a surviving outer ON and pushed down into an eliminated
   inner one).

Fix: after table elimination, walk the expressions that survive into
execution (WHERE, HAVING, select list, ORDER/GROUP BY and the ON
expressions of outer joins that were not eliminated) and clear the
"eliminated" flag on any subquery still reachable from them.

Because a subquery can also be the constant of a multiple equality, and
Item::walk() does not visit an Item_equal's constant, Item_equal gets an
unmark_as_eliminated_processor() override that descends into its constant
explicitly.

When equality propagation (build_equal_items()) merges an equality that
contains a subquery, such as "t1.a = (SELECT ...)", with an outer join's
ON equality, it can inject a reference to that subquery into the ON
expression. If the join columns have compatible types the subquery ends
up as the constant of a multiple equality (which Item::walk() skips); if
they differ (e.g. BIGINT vs INT) the field cannot be merged and the
subquery is substituted in as a plain "tbl.col = (SELECT ...)" argument.

In the latter case, if that outer join is removed by table elimination,
mark_as_eliminated() walks the ON expression and flags the shared
Item_subselect as eliminated. The subquery, however, still lives in
another part of the query and has to be executed, tripping
DBUG_ASSERT(!eliminated) in Item_subselect::exec() (and, in release
builds, disabling the subquery cache and hiding it from EXPLAIN).

The surviving reference can be:
 - a WHERE/HAVING/select-list/ORDER/GROUP expression (subquery written
   there and pushed down into the eliminated ON), or
 - the ON expression of an outer join that was not eliminated (subquery
   written in a surviving outer ON and pushed down into an eliminated
   inner one).

Fix: after table elimination, walk the expressions that survive into
execution (WHERE, HAVING, select list, ORDER/GROUP BY and the ON
expressions of outer joins that were not eliminated) and clear the
"eliminated" flag on any subquery still reachable from them.

Because a subquery can also be the constant of a multiple equality, and
Item::walk() does not visit an Item_equal's constant, Item_equal gets an
unmark_as_eliminated_processor() override that descends into its constant
explicitly.

Assisted by Claude Opus 4.8

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

Copy link
Copy Markdown
Contributor

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 addresses two main issues: MDEV-36610, where a subquery was incorrectly marked as eliminated by table elimination due to equality propagation sharing a WHERE-clause subquery into an eliminated outer join's ON expression, and MDEV-39932, ensuring correct ONLY_FULL_GROUP_BY behavior with outer references in correlated subqueries. To fix MDEV-36610, a new unmark_as_eliminated_processor mechanism was introduced to traverse surviving expressions and clear the 'eliminated' flag on reachable subqueries. For MDEV-39932, changes were made to correctly track non-aggregate fields in Item_field::fix_outer_field and Item_sum::check_sum_func. I have no further feedback to provide as there are no review comments.

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.

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.

2 participants