MDEV-38819 Logic Inconsistency between Direct HAVING Query and Derived Table Relocation#4815
Open
OmarGamal10 wants to merge 1 commit intoMariaDB:10.11from
Open
MDEV-38819 Logic Inconsistency between Direct HAVING Query and Derived Table Relocation#4815OmarGamal10 wants to merge 1 commit intoMariaDB:10.11from
OmarGamal10 wants to merge 1 commit intoMariaDB:10.11from
Conversation
…d Table Relocation This fix restores consistency between the two logically equivalent queries by deep cloning the condition tree before pushing it down from HAVING into WHERE. The issue was caused by the original condition being shared between different optimizer and execution passes.
gkodinov
added
the
External Contribution
gkodinov
approved these changes
Mar 17, 2026
Member
gkodinov
left a comment
gkodinov
left a comment
There was a problem hiding this comment.
Thank you for your contribution! This is a preliminary review.
LGTM. Stay tuned for the final review please.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The inconsistency is caused because the dynamic range scan wrongly attempts to read from an unpopulated temporary table, fails to inject the correct value from the outer table to the inner for the dynamic scan, resulting in a
TREE::IMPOSSIBLEin execution time and giving 0 rows.Tracing through the execution showed that manually modifying the injected value to the inner table led to correct behavior, so the fix was as simple as an if condition in execution time, checking if the temp_table is empty and getting the original value instead, however this scales linearly with the number of rows since it's in execution.
Further investigation showed the root cause lies in the Optimizer's
HAVING clause pushdown. When pushing conditions down to the WHERE clause, the optimizer simply shares pointers to the originalItemfields. Later in the optimization phase, these original fields are mutated (theirresult_fieldis set to point to the empty temp_table, possibly to collect final results). The solution is to copy the fields instead into the pushed down condition, so that they don't undergo the mutation and thus, inject the correct values in the range scan of the inner table.