-
Notifications
You must be signed in to change notification settings - Fork 142
SNOW-2895675: Skip aliases when source/destination column are identical #4037
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Conversation
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
4c19d78 to
3b25773
Compare
sfc-gh-aling
reviewed
Feb 3, 2026
sfc-gh-aling
reviewed
Feb 6, 2026
sfc-gh-aling
approved these changes
Feb 6, 2026
Contributor
sfc-gh-aling
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
sfc-gh-aalam
approved these changes
Feb 6, 2026
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Which Jira issue is this PR addressing? Make sure that there is an accompanying issue to your PR.
Fixes SNOW-2895675
Fill out the following pre-review checklist:
Please describe how your code solves the related issue.
When an alias clause would emit an alias that does not change an input column's name, as in
SELECT "A" AS "A", the alias is elided to justSELECT "A". This PR also includes a fix from @sfc-gh-aling to emitSELECT *(rather thanSELECT "col1", "col2") in join operations if no aliasing is necessary.As a result, the SQL for the final query emitted by
test_dataframe_join_suite.py::test_name_alias_on_multiple_joinis reduced from 1045B -> 799B, a 24% reduction. This fix was requested for SCOS; a sample query emulating a user workload similarly experiences a 15% reduction in query size in SCOS (2175B -> 1857B), and a 60% reduction for the Snowpark equivalent (328B -> 128B).Implementation Details
Though the original ask was specifically to implement this change for JOIN operations, this PR applies the optimization to all generated queries. It does so with changes in three locations:
unary_expression_extractorinanalyzer.py: Avoids emitting SQL for an alias in locations when possible, when traversing a query plan. This is the simplest location to make this change, as it avoids the need to track down all call sites that generate anAliasnode.derive_column_states_from_subqueryinselect_statement.py: This method compares the analyzed query strings of expressions to see if their values have changed. Previously, aliases always fully resolved ("A" AS "A"), so aliased columns were always assigned the CHANGED_EXP state; now, since redundant aliases resolve to just the column name ("A"), this method assigns UNCHANGED_EXP instead. My understanding is that this behavior should be correct, but this produced bugs in nested joins where a top-level projection did not properly use an alias for an ambiguous column._disambiguateindataframe.py: If two frames have no column names in common at all, then there is no need for disambiguation, and we can simply emit aSELECT *. This fix was proposed by @sfc-gh-aling in SNOW-2895675: removing redundant alias when join #4044.I could not track down the root cause of the aliasing issue, as it appeared even with simpler fixes like modifying
_alias_if_neededindataframe.py, and replacing analyzer calls withparse_local_nameas suggested by comments withinselect_statement.py. Based on running through the codebase (and asking Cursor), it is likely that a subquery alias mapping somewhere is not being populated somewhere during analysis, but it is not clear what step of the analysis process would be responsible for this.The fix I chose provides the largest benefit (removing redundant aliasing for all queries, not just joins) while adhering as closely as possible to previous behavior when analyzing column change states.
Why do we need to change both the analyzer and join disambiguation?
In cases where frames have no overlapping column names, the fix in #4044 to emit
SELECT *instead of individual column names is sufficient. This can also lead to a reduction in issued DESCRIBE queries. Example:However, if frames do have overlapping column names, explicit removal of aliasing is necessary to reduce query text size. This is a very realistic scenario, as JOIN operations frequently combine tables based on a common ID column or other key. Example:
The changes in this PR do not reduce the number of queries issued for this case, but can lead to a substantial reduction in text size when a joined DF is used repeatedly in a sub-query.