Repository navigation
avoid quadratic member lookups in table and alias visitors - #2763
Merged
manticore-projects merged 1 commit intoOct 11, 2026
Merged
Conversation
TablesNamesFinder tracked derived-table, CTE and lateral names in an ArrayList and matched every plain table reference against it, and AddAliasesVisitor checked each generated alias against a LinkedList, so both walked parsed SQL in O(n^2). Both collections are used only for membership, so back them with a LinkedHashSet. Signed-off-by: Javid Khan <dxbjavid@gmail.com>
Contributor
|
Kudos for knowing/understanding the Java Collection classes and Lists :-D |
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.
TablesNamesFinder remembers the names of derived tables, CTEs and lateral selects in otherItemNames and checks every plain table reference against it before recording it, but that collection was an ArrayList, so the membership test was linear and a statement with n aliased items and n table references took O(n^2) to walk through findTables. The same shape affects AddAliasesVisitor, where each generated alias is checked against the already used ones with a LinkedList.contains, so adding aliases to a select with n items was quadratic as well. Both collections are only ever used for membership, never for ordering, so backing them with a LinkedHashSet keeps the output identical while bringing both walks back to linear; I have added a timing regression test for each.