-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
[opt](nereids) infer in-predicate from or-predicate #46468
Conversation
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
run buildall |
TPC-H: Total hot run time: 32462 ms
|
TPC-DS: Total hot run time: 190911 ms
|
ClickBench: Total hot run time: 31.09 s
|
run buildall |
TPC-H: Total hot run time: 32809 ms
|
TPC-DS: Total hot run time: 197193 ms
|
ClickBench: Total hot run time: 31.16 s
|
run p0 |
PR approved by at least one committer and no changes requested. |
PR approved by anyone and no changes requested. |
fe/fe-core/src/main/java/org/apache/doris/nereids/rules/expression/rules/OrToIn.java
Show resolved
Hide resolved
run buildall |
fe/fe-core/src/main/java/org/apache/doris/nereids/rules/expression/rules/OrToIn.java
Outdated
Show resolved
Hide resolved
run buildall |
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.
LGTM
TPC-H: Total hot run time: 32843 ms
|
TPC-DS: Total hot run time: 194895 ms
|
ClickBench: Total hot run time: 32.15 s
|
run p0 |
run cloud_p0 |
run p0 |
2 similar comments
run p0 |
run p0 |
run buildall |
TPC-H: Total hot run time: 33323 ms
|
TPC-DS: Total hot run time: 194787 ms
|
ClickBench: Total hot run time: 31.37 s
|
PR approved by at least one committer and no changes requested. |
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.
LGTM
What problem does this PR solve?
previous verion has follow drawbacks
in order to solve above issues, we implemented a new version
first, it is a plan node level rule to avoid to be applied to the same expression repeatedly
second, we define replace mode and extract mode. if in replace mode, the original expression should be equivalent to the inferred in-pred, which is used for all plan node's expressions except filter.
for example, orig = "(a=1 and b=1) or (a=2 and c=2)" is equivalent to "a in (1, 2) and (a=1 and b=1) or (a=2 and c=2)".
orig is a filter condition, "a in (1, 2)" can be pushed down to storage layer, and this infer is useful. But if this is orig is an other join condition, this inferrence is useless. So in extract mode, "a in (1, 2)" is inferred, but in replace mode, it is not.
Issue Number: close #xxx
Related PR: #xxx
Problem Summary:
Release note
None
Check List (For Author)
Test
Behavior changed:
Does this need documentation?
Check List (For Reviewer who merge this PR)