-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-9778][SQL] remove unnecessary evaluation from SortOrder #8066
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
Conversation
|
cc @marmbrus |
|
retest this please. |
|
Test build #40290 has finished for PR 8066 at commit
|
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.
I would be good if we could just do this as part of CleanAliases in #7957. Basically it seems that there is no reason to have an Alias except as a top level expression in Project or Aggregate.
a1fabce to
abc0fc3
Compare
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.
We can't do this optimization in Analyzer.ResolveSortReferences as the aggregate expressions inside ordering expression are unresolved at that time. We need to add them to underlying Aggregate first and let other rules to resolve them.
|
Test build #40960 has finished for PR 8066 at commit
|
|
Test build #40965 has finished for PR 8066 at commit
|
|
Test build #40962 has finished for PR 8066 at commit
|
|
Test build #40964 has finished for PR 8066 at commit
|
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.
Use semanticEquals or sameRef instead?
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.
We should not do this optimization during analysis. Logically optimizations should go into Optimizer, and for this case, the match may fail because of non-complete Cast expressions caused by type coercion rules
|
Test build #42098 has finished for PR 8066 at commit
|
|
ping @marmbrus |
|
Test build #42870 has finished for PR 8066 at commit
|
|
Hi @marmbrus , I updated it and did some simplification, could you take a look? Thanks! |
|
Test build #47071 has finished for PR 8066 at commit
|
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.
nit: could you do e.asc instead?
|
Test build #47073 has finished for PR 8066 at commit
|
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.
Nit: to follow the other suites this would probably be SortOptimizationSuite
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.
Would this be simpler as a find?
|
A few minor comments, overall LGTM. |
d5fdeff to
1cc52f2
Compare
|
Test build #47138 has finished for PR 8066 at commit
|
|
Test build #47141 has finished for PR 8066 at commit
|
|
Test build #47142 has finished for PR 8066 at commit
|
|
Test build #56519 has finished for PR 8066 at commit
|
|
Test build #56521 has finished for PR 8066 at commit
|
|
retest this please. |
|
Test build #56624 has finished for PR 8066 at commit
|
|
Test build #56666 has finished for PR 8066 at commit
|
|
Close this? |
|
Do you mind if I ask why it was asked to be closed? (I am just purely curious while looking through PRs and JIRAs). |
If the order-by expression is already in child's output, we can just reference it instead of evaluate it agian.