-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-32995][SQL] CostBasedJoinReorder optimizer rule should be idempotent #29871
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
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/CostBasedJoinReorder.scala
Outdated
Show resolved
Hide resolved
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/optimizer/CostBasedJoinReorder.scala
Outdated
Show resolved
Hide resolved
|
@LuciferYang, it seems you were working on similar issue, but you closed it - #29638 |
|
Kubernetes integration test starting |
|
Kubernetes integration test starting |
|
Kubernetes integration test status failure |
|
Kubernetes integration test status failure |
|
Closing for now, because there is some issue with the golden files |
|
Test build #129118 has finished for PR 29871 at commit
|
|
Test build #129116 has finished for PR 29871 at commit
|
|
If there are multiple candidate plans with same cost, I think |
With this change optimally ordered input doesn't get reordered into another plan with the same cost - this makes I had a wrong approach to solving this earlier, now it should stable. |
|
Test build #129154 has finished for PR 29871 at commit
|
|
Kubernetes integration test starting |
|
Kubernetes integration test starting |
|
Kubernetes integration test status failure |
|
Kubernetes integration test status failure |
|
Test build #129155 has finished for PR 29871 at commit
|
|
Does this PR affect the behavior in Scala 2.13? Can you help verify it offline? |
|
Have you checked actuall performance changes with sf=100? I think it would be better to check them for avoiding accidental performance regression. |
|
Test build #133658 has finished for PR 29871 at commit
|
|
Now that #30965 is merged, this changes the plans a lot less. |
|
Kubernetes integration test starting |
|
Kubernetes integration test status failure |
|
Test build #133685 has finished for PR 29871 at commit
|
|
Kubernetes integration test starting |
|
Kubernetes integration test status success |
|
Test build #134148 has finished for PR 29871 at commit
|
|
Kubernetes integration test starting |
|
Kubernetes integration test starting |
|
Kubernetes integration test status failure |
|
Kubernetes integration test status success |
|
Test build #134517 has finished for PR 29871 at commit
|
|
Kubernetes integration test starting |
|
Kubernetes integration test status failure |
|
Test build #136280 has finished for PR 29871 at commit
|
|
Kubernetes integration test starting |
|
Kubernetes integration test status failure |
|
Test build #136850 has finished for PR 29871 at commit
|
|
We're closing this PR because it hasn't been updated in a while. This isn't a judgement on the merit of the PR in any way. It's just a way of keeping the PR queue manageable. |
What changes were proposed in this pull request?
Mark the "Join Reorder" batch as idempotent.
The CostBasedJoinReorder needed a slight modification to satisfy this rule.
There are some changes in the plan stability suite. They are caused by changing the iteration order in CostBasedJoinReorder.
Why are the changes needed?
Idempotence check on optimizer batches is invaluable for developers. It can avoid us bugs in the future.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Existing UTs mostly cover it, also added one extra