-
Notifications
You must be signed in to change notification settings - Fork 28.9k
[SPARK-28863][SQL][FOLLOWUP] Make sure optimized plan will not be re-analyzed #30777
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
|
Kubernetes integration test starting |
|
Kubernetes integration test status success |
|
Test build #132812 has finished for PR 30777 at commit
|
|
cc @brkyvz |
|
The change looks reasonable to me. |
…analyzed ### What changes were proposed in this pull request? It's a known issue that re-analyzing an optimized plan can lead to various issues. We made several attempts to avoid it from happening, but the current solution `AlreadyOptimized` is still not 100% safe, as people can inject catalyst rules to call analyzer directly. This PR proposes a simpler and safer idea: we set the `analyzed` flag to true after optimization, and analyzer will skip processing plans whose `analyzed` flag is true. ### Why are the changes needed? make the code simpler and safer ### Does this PR introduce _any_ user-facing change? no ### How was this patch tested? existing tests. Closes #30777 from cloud-fan/ds. Authored-by: Wenchen Fan <[email protected]> Signed-off-by: HyukjinKwon <[email protected]> (cherry picked from commit b4bea1a) Signed-off-by: HyukjinKwon <[email protected]>
|
Merged to master and branch-3.1. @cloud-fan, it has a conflict with branch-3.0. Do you mind opening a backport PR? |
|
late LGTM. I believe this is a much more robust solution |
…analyzed It's a known issue that re-analyzing an optimized plan can lead to various issues. We made several attempts to avoid it from happening, but the current solution `AlreadyOptimized` is still not 100% safe, as people can inject catalyst rules to call analyzer directly. This PR proposes a simpler and safer idea: we set the `analyzed` flag to true after optimization, and analyzer will skip processing plans whose `analyzed` flag is true. make the code simpler and safer no existing tests. Closes apache#30777 from cloud-fan/ds. Authored-by: Wenchen Fan <[email protected]> Signed-off-by: HyukjinKwon <[email protected]> (cherry picked from commit b4bea1a) Signed-off-by: HyukjinKwon <[email protected]>
…e re-analyzed backport #30777 to 3.0 ---------- ### What changes were proposed in this pull request? It's a known issue that re-analyzing an optimized plan can lead to various issues. We made several attempts to avoid it from happening, but the current solution `AlreadyOptimized` is still not 100% safe, as people can inject catalyst rules to call analyzer directly. This PR proposes a simpler and safer idea: we set the `analyzed` flag to true after optimization, and analyzer will skip processing plans whose `analyzed` flag is true. ### Why are the changes needed? make the code simpler and safer ### Does this PR introduce _any_ user-facing change? no ### How was this patch tested? existing tests. Closes #30872 from cloud-fan/ds. Authored-by: Wenchen Fan <[email protected]> Signed-off-by: HyukjinKwon <[email protected]>
What changes were proposed in this pull request?
It's a known issue that re-analyzing an optimized plan can lead to various issues. We made several attempts to avoid it from happening, but the current solution
AlreadyOptimizedis still not 100% safe, as people can inject catalyst rules to call analyzer directly.This PR proposes a simpler and safer idea: we set the
analyzedflag to true after optimization, and analyzer will skip processing plans whoseanalyzedflag is true.Why are the changes needed?
make the code simpler and safer
Does this PR introduce any user-facing change?
no
How was this patch tested?
existing tests.