-
Notifications
You must be signed in to change notification settings - Fork 25.2k
ESQL - Remove restrictions for disjunctions in full text functions #118544
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
ESQL - Remove restrictions for disjunctions in full text functions #118544
Conversation
Pinging @elastic/es-analytical-engine (Team:Analytics) |
Hi @carlosdelest, I've created a changelog YAML for you. |
…junction-restrictions' into enhancement/esql-match-disjunction-restrictions
@@ -102,6 +102,64 @@ book_no:keyword | title:text | |||
7140 |The Lord of the Rings Poster Collection: Six Paintings by Alan Lee (No. 1) | |||
; | |||
|
|||
|
|||
matchWithDisjunction | |||
required_capability: match_function |
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.
We might need to add a new esql capability if the bwc tests fail 🤔
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.
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.
I love this ! 🤟
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.
This is a great improvement. I left a few small comments.
x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/analysis/Verifier.java
Outdated
Show resolved
Hide resolved
x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/analysis/Verifier.java
Outdated
Show resolved
Hide resolved
x-pack/plugin/esql/qa/testFixtures/src/main/resources/match-function.csv-spec
Show resolved
Hide resolved
x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/analysis/Verifier.java
Outdated
Show resolved
Hide resolved
...ql/src/test/java/org/elasticsearch/xpack/esql/optimizer/LocalPhysicalPlanOptimizerTests.java
Outdated
Show resolved
Hide resolved
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, great work Carlos!
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.
Just a final thing to consider (which could be just my misunderstanding, I didn't double check!). Are we ok when the filter has a top-level conjunction, followed by a disjunction within the right-size clause? e.g.
| WHERE content:"fox" AND ( match(foo, "xx") OR to_upper(content) == "FOX"
)`
@ChrisHegarty , that's an error and is checked by this test. |
// Exit early if we already have a failures | ||
return; | ||
} | ||
Expression left = or.left(); |
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.
Is my understanding right, that the goal of checkFullTextSearchDisjunctions
is - if there is FullTextFunction
exists under Or
, all of the children of the Or
have to be FullTextFunction
s? If this is true, can this algorithm be simplified, instead of checking onlyFullTextFunctionsInExpression
, can we check nonFullTextFunctionExists
on either sides of the Or
?
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.
Sorry, I'm not following - can you please elaborate with an example?
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.
I'm thinking if we can simplify the logic here. Will something like this work? Do we need to check both sides separately?
boolean hasFullText = or.anyMatch(FullTextFunction.class::isInstance);
boolean hasOnlyFullText = onlyFullTextFunctionsInExpression(or);
if (hasFullText) {
if (hasOnlyFullText) {
// succeed
} else {
// fail
}
} else {
// succeed
}
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.
Thanks for explaining, I see your point. I was trying to get the sub-expression that is at fault, so we can add that to the failure message. But maybe that's not super helpful and we can just error out with:
Invalid condition [first_name:"Anna" or starts_with(first_name, "Anne")]. Full text functions can be used in an OR condition, but only if just full text functions are used in the OR condition
instead of the previous:
Invalid condition [first_name:"Anna" or starts_with(first_name, "Anne")]. [:] operator can be used in an OR condition, but only if just full text functions are used in the OR condition
I have simplified this in 8901591, LMKWYT and I can keep or revert it to the previous one.
…n-restrictions # Conflicts: # x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/action/EsqlCapabilities.java
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.
Thank you @carlosdelest, LGTM
@elasticmachine run elasticsearch-ci/part-4 |
💔 Backport failed
You can use sqren/backport to manually backport by running |
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
…lastic#118544) (cherry picked from commit 3f1fed0) # Conflicts: # x-pack/plugin/esql/src/test/java/org/elasticsearch/xpack/esql/optimizer/LocalPhysicalPlanOptimizerTests.java
Full Text functions are currently limited - they cannot be used as part of disjunctions, as there is not a reliable way of understanding if an expression is pushable to Lucene on the coordinator node.
Something we can do in order to lift that restriction is to ensure that when a full text function is used as part of a disjunction, then all the elements in the disjunction are full text functions, so we know for sure that they can be pushed to Lucene.
This PR checks the above, and adds testing to it.