fix(optimizer): do not push predicates into a subquery with LIMIT/OFFSET [CLAUDE]#7901
Merged
georgesittas merged 1 commit intoJul 20, 2026
Merged
Conversation
…ET [CLAUDE] pushdown_predicates already refuses to push a predicate into a subquery that carries a GROUP BY or a window function, because doing so would change the result. A LIMIT or OFFSET has the same problem: it picks rows before the outer predicate runs, so filtering inside the subquery changes which rows the limit keeps. For example SELECT s.x FROM (SELECT x, y FROM t ORDER BY x LIMIT 10) AS s WHERE s.y > 5 was rewritten to filter y > 5 *before* the LIMIT, silently returning different rows. Extend the existing guard to also bail on limit/offset. Co-authored-by AI: Claude (Claude Code). [CLAUDE]
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.
pushdown_predicatesalready refuses to push a predicate into a single-tablesubquery that carries a
GROUP BYor a window function, since either wouldchange the result.
LIMIT/OFFSEThas the same issue: it selects rowsbefore the outer predicate runs, so pushing the filter in changes which rows
survive the limit.
The rewrite filters
y > 5before theLIMIT 10, so it returns rows theoriginal query would never see — a silent change of results. The same happens
with a bare
OFFSET.Extended the existing guard to also bail when the subquery has a
limitoroffset. Subqueries without either still get the predicate pushed down asbefore. Added two fixture cases (LIMIT and OFFSET) that assert the query is
left unchanged;
make unitpasses.This PR was authored by an AI coding agent (Claude Code) running on this account:
the AI found the bug, ran the repro, wrote the tests, and wrote this description.
The human account holder reviews every change and is accountable for it. The
verification above is real and re-runnable from the diff. If this isn't the kind
of contribution you want, say so and I'll close it.