-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
[Enhancement] remove partition version check in plan validation (backport #46733) #46781
Conversation
Signed-off-by: packy92 <[email protected]> (cherry picked from commit 8b91707) # Conflicts: # fe/fe-core/src/main/java/com/starrocks/catalog/OlapTable.java # fe/fe-core/src/main/java/com/starrocks/sql/OptimisticVersion.java # fe/fe-core/src/main/java/com/starrocks/sql/StatementPlanner.java # fe/fe-core/src/test/java/com/starrocks/lake/LakeTableTest.java # fe/fe-core/src/test/java/com/starrocks/sql/OptimisticVersionTest.java
Cherry-pick of 8b91707 has failed:
To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
@mergify[bot]: Backport conflict, please reslove the conflict and resubmit the pr |
Signed-off-by: packy92 <[email protected]>
Signed-off-by: packy92 <[email protected]>
Quality Gate passedIssues Measures |
Why I'm doing:
In a large number of real-time import scenarios, if a complex query contains multiple tables, verifying the partitioned versions of multiple tables may still cause the plan to fail.
What I'm doing:
When the partition is shallow copied, the version number is copied while holding the lock, and the historical snapshot version can be used for query. So we can remove this partition version check.
Fixes #issue
What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist:
Bugfix cherry-pick branch check:
This is an automatic backport of pull request #46733 done by [Mergify](https://mergify.com). ## Why I'm doing: In a large number of real-time import scenarios, if a complex query contains multiple tables, verifying the partitioned versions of multiple tables may still cause the plan to fail. ![image](https://github.com/StarRocks/starrocks/assets/110370499/12eb6762-137f-41dc-8735-895db91a10f2)
What I'm doing:
When the partition is shallow copied, the version number is copied while holding the lock, and the historical snapshot version can be used for query. So we can remove this partition version check.
Fixes #issue
What type of PR is this:
Does this PR entail a change in behavior?
If yes, please specify the type of change:
Checklist: