-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
[Fix](Nereids) fix test leading random failed #23657
Conversation
run buildall |
1 similar comment
run buildall |
run p0 |
1 similar comment
run p0 |
run buildall |
8f53b67
to
1776b07
Compare
run buildall |
1776b07
to
c315c4c
Compare
run buildall |
run p0 |
run buildall |
c315c4c
to
a4fbae7
Compare
run buildall |
a4fbae7
to
855a20c
Compare
run buildall |
(From new machine)TeamCity pipeline, clickbench performance test result: |
run buildall |
(From new machine)TeamCity pipeline, clickbench performance test result: |
run buildall |
(From new machine)TeamCity pipeline, clickbench performance test result: |
855a20c
to
255e8e2
Compare
run buildall |
(From new machine)TeamCity pipeline, clickbench performance test result: |
@@ -41,7 +41,7 @@ public Plan rewriteRoot(Plan plan, JobContext jobContext) { | |||
(LeadingHint) leadingHint, ((LeadingHint) leadingHint) | |||
.getLeadingTableBitmap(jobContext.getCascadesContext().getTables()))); | |||
if (leadingHint.isSuccess()) { | |||
jobContext.getCascadesContext().getConnectContext().getSessionVariable().setDisableJoinReorder(true); | |||
jobContext.getCascadesContext().getConnectContext().getStatementContext().setDisableJoinReorder(true); |
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.
u could refer to org.apache.doris.qe.SessionVariable#enableFallbackToOriginalPlannerOnce
to change session variable for only one sql
255e8e2
to
da069de
Compare
run buildall |
(From new machine)TeamCity pipeline, clickbench performance test result: |
da069de
to
c0558e3
Compare
run buildall |
(From new machine)TeamCity pipeline, clickbench performance test result: |
run buildall |
(From new machine)TeamCity pipeline, clickbench performance test result: |
c0558e3
to
5847d1f
Compare
run buildall |
(From new machine)TeamCity pipeline, clickbench performance test result: |
run p0 |
2 similar comments
run p0 |
run p0 |
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
…apache#23657) Problem: when running pipeline, we get randomly failed of test_leading Reason: physical distribute was generated and choosed to be the best plan because we can not get any statistic information of empty table. So we would get some unexpect result because we can not expect the order in memo Solved: Add statistic of columns used in test_leading, try repeatly in pipeline
…apache#23657) Problem: when running pipeline, we get randomly failed of test_leading Reason: physical distribute was generated and choosed to be the best plan because we can not get any statistic information of empty table. So we would get some unexpect result because we can not expect the order in memo Solved: Add statistic of columns used in test_leading, try repeatly in pipeline
…apache#23657) Problem: when running pipeline, we get randomly failed of test_leading Reason: physical distribute was generated and choosed to be the best plan because we can not get any statistic information of empty table. So we would get some unexpect result because we can not expect the order in memo Solved: Add statistic of columns used in test_leading, try repeatly in pipeline
…apache#23657) Problem: when running pipeline, we get randomly failed of test_leading Reason: physical distribute was generated and choosed to be the best plan because we can not get any statistic information of empty table. So we would get some unexpect result because we can not expect the order in memo Solved: Add statistic of columns used in test_leading, try repeatly in pipeline
…apache#23657) Problem: when running pipeline, we get randomly failed of test_leading Reason: physical distribute was generated and choosed to be the best plan because we can not get any statistic information of empty table. So we would get some unexpect result because we can not expect the order in memo Solved: Add statistic of columns used in test_leading, try repeatly in pipeline
…apache#23657) Problem: when running pipeline, we get randomly failed of test_leading Reason: physical distribute was generated and choosed to be the best plan because we can not get any statistic information of empty table. So we would get some unexpect result because we can not expect the order in memo Solved: Add statistic of columns used in test_leading, try repeatly in pipeline
* [Feat](Nereids) Add leading and ordered hint (#22057) Add leading hint and ordered hint. Usage: select /*+ ordered / * from a join b on xxx; which will limit join order to original order select /+ leading ({b a}) */ from a join b on xxx; which will change join order to b join a. * [Fix](Nereids) fix test leading change disable join reorder parameter (#23657) Problem: when running pipeline, we get randomly failed of test_leading Reason: physical distribute was generated and choosed to be the best plan because we can not get any statistic information of empty table. So we would get some unexpect result because we can not expect the order in memo Solved: Add statistic of columns used in test_leading, try repeatly in pipeline * [Fix](Nereids) fix test leading suite and add tpch shape checking base on leading (#25842) - fix test leading suite caused by sessionvariable setting error - add tpch shape checking base on leading * [Feat](Nereids) join hint support stage one (#27378) support view as a independent unit of leading hint add random test check of leading hint query add more test with data of leading hint query add random test check of distribute hint * [Fix](Nereids) fix leading rebase problems
Proposed changes
Problem:
when running pipeline, we get randomly failed of test_leading
Reason:
physical distribute was generated and choosed to be the best plan because we can not get any statistic information of empty table. So we would get some unexpect result because we can not expect the order in memo
Solved:
Add statistic of columns used in test_leading, try repeatly in pipeline
Further comments
If this is a relatively large or complex change, kick off the discussion at dev@doris.apache.org by explaining why you chose the solution you did and what alternatives you considered, etc...