Parser: fix exponential parse time on table-factor paren chains#2
Merged
moshap-firebolt merged 1 commit intoJun 9, 2026
Conversation
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 5005c3f. Configure here.
5005c3f to
313b536
Compare
`parse_table_factor` speculatively parses `(...)` as a derived table; on failure it rewinds and falls through to `parse_table_and_joins`, which recurses back into `parse_table_factor` and re-attempts the same speculative parse at every deeper paren. Both arms walk the remaining chain, so on inputs like `SELECT 1 FROM ((((...` work doubles per level. Caching the position at which the speculative arm failed short-circuits the second descent. Measured on `GenericDialect` with `with_recursion_limit(256)`, release build: | N | Before | After | |----|---------|--------| | 10 | 20 ms | 57 us | | 20 | 820 ms | 119 us | | 25 | 2.8 s | 281 us | | 30 | 7.9 s | 345 us |
313b536 to
dd977d0
Compare
2c43850
into
firebolt/v0.62.0-pathological
2 checks passed
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
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.

parse_table_factorspeculatively parses(...)as a derived table; onfailure it rewinds and falls through to
parse_table_and_joins, whichrecurses back into
parse_table_factorand re-attempts the samespeculative parse at every deeper paren. Both arms walk the remaining
chain, so on inputs like
SELECT 1 FROM ((((...work doubles per level.Caching the position at which the speculative arm failed short-circuits
the second descent.
Measured on
GenericDialectwithwith_recursion_limit(256), releasebuild:
Cherry-picked upstream as apache#2372 (against
apache:main). Merging here so PackDB can pick the fix up while upstream review lands.Note
Medium Risk
Touches core SQL
FROM/join parsing with speculative-parse behavior; change is narrow (failure memoization only) but affects a hot, recursive path.Overview
Fixes exponential parse time on malformed
FROMinputs with long unclosed parenthesis chains (e.g.SELECT 1 FROM ((((...), whereparse_table_factorrepeatedly tried the derived-table path and the nested-join fallback on the same token positions.Adds a
failed_derived_table_factor_positionscache onParser(cleared when tokens reset). Before callingparse_derived_table_factor, the parser skips positions already known to fail and records new failures so the nested-join path does not re-run the same speculative work.Includes a timeout regression test and a Criterion benchmark (
parse_table_factor_paren_chain) aligned with existing prefix/compound-chain perf benches.Reviewed by Cursor Bugbot for commit dd977d0. Bugbot is set up for automated code reviews on this repo. Configure here.