-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Convert LIKE to ranges #3618
Convert LIKE to ranges #3618
Conversation
f4cf7f3
to
f57fb93
Compare
Added a plan test verifying the pushdown end-to-end. |
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.
Some minor comments. My only concern is that this optimization may break if something upstream replaced LIKE with a function call (or if we get rid of LIKE from the IR -- which will certainly happen at some point)
presto-main/src/main/java/io/prestosql/sql/planner/DomainTranslator.java
Outdated
Show resolved
Hide resolved
presto-main/src/main/java/io/prestosql/sql/planner/DomainTranslator.java
Show resolved
Hide resolved
presto-main/src/main/java/io/prestosql/sql/planner/DomainTranslator.java
Outdated
Show resolved
Hide resolved
presto-main/src/main/java/io/prestosql/sql/planner/DomainTranslator.java
Outdated
Show resolved
Hide resolved
I agree, that's why i added a plan test that verifies things end-to-end, at the connector table handle level. When we move away into more powerful predicate pushdowns, things like TupleDomain will gain "better versions of themselves", and this test (every such test) will need to be updated for the new API, but it will be still applicable to verify mechanics on the higher level. And we will be able to make educated decisions on any potential steps backwards if absolutely needed. |
Applied |
Ship it! |
No description provided.