-
Notifications
You must be signed in to change notification settings - Fork 28.9k
[SPARK-46485][SQL][3.5] V1Write should not add Sort when not needed #52692
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
### What changes were proposed in this pull request? In `V1Writes`, we try to avoid adding Sort if the output ordering always satisfies. However, the code is completely broken with two issues: - we put `SortOrder` as the child of another `SortOrder` and compare, which always returns false. - once we add a project to do `empty2null`, we change the query output attribute id and the sort order never matches. It's not a big issue as we still have QO rules to eliminate useless sorts, but apache#44429 exposes this problem because the way we optimize sort is a bit different. For `V1Writes`, we should always avoid adding sort even if the number of ordering key is less, to not change the user query. ### Why are the changes needed? fix code mistakes. ### Does this PR introduce _any_ user-facing change? no ### How was this patch tested? updated test ### Was this patch authored or co-authored using generative AI tooling? no Closes apache#44458 from cloud-fan/sort. Authored-by: Wenchen Fan <[email protected]> Signed-off-by: Wenchen Fan <[email protected]>
|
do we need to cherry-pick the test change as well? |
No because, https://github.com/apache/spark/pull/44429/files#diff-0779e15156e4b0580442d540cc5f60fcee06a454b7f5fcbc4be67f33cec6069bR226-R243 never landed on 3.5. The test change just reverts that. |
Backport #44458 to branch-3.5. Justification: it fixes a hidden bug (until exposed by #44429) that has existed since 3.4. ### What changes were proposed in this pull request? In `V1Writes`, we try to avoid adding Sort if the output ordering always satisfies. However, the code is completely broken with two issues: - we put `SortOrder` as the child of another `SortOrder` and compare, which always returns false. - once we add a project to do `empty2null`, we change the query output attribute id and the sort order never matches. It's not a big issue as we still have QO rules to eliminate useless sorts, but #44429 exposes this problem because the way we optimize sort is a bit different. For `V1Writes`, we should always avoid adding sort even if the number of ordering key is less, to not change the user query. ### Why are the changes needed? fix code mistakes. ### Does this PR introduce _any_ user-facing change? no ### How was this patch tested? updated test ### Was this patch authored or co-authored using generative AI tooling? no Closes #52692 from pan3793/SPARK-46485-3.5. Authored-by: Wenchen Fan <[email protected]> Signed-off-by: Peter Toth <[email protected]>
|
Thanks, merged to @pan3793, can you please open a SPARK-53738 / #52584 backport PR as well? |
|
@peter-toth thanks, I have opened #52697 for SPARK-53738 |
Backport #44458 to branch-3.5.
Justification: it fixes a hidden bug (until exposed by #44429) that has existed since 3.4.
What changes were proposed in this pull request?
In
V1Writes, we try to avoid adding Sort if the output ordering always satisfies. However, the code is completely broken with two issues:SortOrderas the child of anotherSortOrderand compare, which always returns false.empty2null, we change the query output attribute id and the sort order never matches.It's not a big issue as we still have QO rules to eliminate useless sorts, but #44429 exposes this problem because the way we optimize sort is a bit different. For
V1Writes, we should always avoid adding sort even if the number of ordering key is less, to not change the user query.Why are the changes needed?
fix code mistakes.
Does this PR introduce any user-facing change?
no
How was this patch tested?
updated test
Was this patch authored or co-authored using generative AI tooling?
no