[ES|QL] Rewrite In with EvaluatorMapper#109413
Conversation
...lugin/esql/compute/gen/src/main/java/org/elasticsearch/compute/gen/EvaluatorImplementer.java
Outdated
Show resolved
Hide resolved
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
...lugin/esql/compute/gen/src/main/java/org/elasticsearch/compute/gen/EvaluatorImplementer.java
Outdated
Show resolved
Hide resolved
...lugin/esql/compute/gen/src/main/java/org/elasticsearch/compute/gen/EvaluatorImplementer.java
Outdated
Show resolved
Hide resolved
x-pack/plugin/esql/qa/testFixtures/src/main/resources/ip.csv-spec
Outdated
Show resolved
Hide resolved
.../src/main/java/org/elasticsearch/xpack/esql/expression/predicate/operator/comparison/In.java
Show resolved
Hide resolved
...lugin/esql/compute/gen/src/main/java/org/elasticsearch/compute/gen/EvaluatorImplementer.java
Outdated
Show resolved
Hide resolved
.../src/main/java/org/elasticsearch/xpack/esql/expression/predicate/operator/comparison/In.java
Show resolved
Hide resolved
...k/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/optimizer/LogicalPlanOptimizer.java
Outdated
Show resolved
Hide resolved
.../src/main/java/org/elasticsearch/xpack/esql/expression/predicate/operator/comparison/In.java
Outdated
Show resolved
Hide resolved
nik9000
left a comment
There was a problem hiding this comment.
I like this much more! I left a few questions, but I think this seems like the right thing to do for IN.
...rg/elasticsearch/xpack/esql/expression/predicate/operator/comparison/InBooleanEvaluator.java
Outdated
Show resolved
Hide resolved
...rg/elasticsearch/xpack/esql/expression/predicate/operator/comparison/InBooleanEvaluator.java
Outdated
Show resolved
Hide resolved
.../src/main/java/org/elasticsearch/xpack/esql/expression/predicate/operator/comparison/In.java
Show resolved
Hide resolved
| } | ||
| } | ||
|
|
||
| public static class InComparisons extends ExpressionTranslator<In> { |
There was a problem hiding this comment.
I think we're moving these into their own top level file more often these days.
There was a problem hiding this comment.
I think we're moving these into their own top level file more often these days.
I just double checked, a lot of LogicalPlanOptimizer rules are in their own top level files, under optimizer/rules, the ExpressionTranslators are not in their own files yet. They are in either EsqlExpressionTranslators or ExpressionTranslators in esql-core. Perhaps keep it here for now?
| continue; | ||
| } | ||
| try { | ||
| In.process(result, nulls, mvs, lhsBlock.getBoolean(lhsBlock.getFirstValueIndex(p)), rhsValues); |
There was a problem hiding this comment.
I wonder - should booleans be special and not use the array method? Ultimately IN (true) and IN (false) and IN () and IN (false, true) are the only possible layouts. Right? IN (false, false) has the same meaning as IN (false)`. I think.
If that's true, then this is useful: I've found sometimes I don't use the string template stuff for boolean because it's so different. In this case maybe I'd slurp more of this method into In.process's boolean flavor. But whatever make the hacking easy I'm for. I don't have a strong opinion about the right way to lay out these templates.
There was a problem hiding this comment.
Indeed, I'll simplify boolean. I ended up modifying the template to generate evaluator for boolean, as it makes it easier to handle warnings consistently with other types.
...g/elasticsearch/xpack/esql/expression/predicate/operator/comparison/InBytesRefEvaluator.java
Outdated
Show resolved
Hide resolved
Thanks for reviewing it again @nik9000 ! Most of the comments are addressed, and I cleaned it up according to the suggestions, simplified boolean a bit, left |
nik9000
left a comment
There was a problem hiding this comment.
Looks good to me. I left a question about the Analyzer but that's pretty far outside my area of expertise so I'm happy to trust about moving that invocation rather than merging.
| } | ||
| if (f instanceof In in) { | ||
| return processIn(in); | ||
| } |
There was a problem hiding this comment.
Can we use processScalarFunction for this one or is it incompatible somehow?
There was a problem hiding this comment.
Can we use
processScalarFunctionfor this one or is it incompatible somehow?
This is a good point! It is not quite compatible for now, one reason is that In is not a registered function yet, it is under operator/comparison, there will be a little more work to make it a registered function. I'll look into it, and if possible, create a follow up PR for it.
| import org.elasticsearch.compute.data.BytesRefVector; | ||
| $elseif(boolean)$ | ||
| import org.elasticsearch.compute.data.BooleanVector; | ||
| $endif$ |
There was a problem hiding this comment.
I've tried to remove the import order rules from this generated code but it's a huge pain. I'm sorry about this mess.
| } | ||
| } | ||
|
|
||
| public static class InComparisons extends ExpressionTranslator<In> { |
Quick cleanup PR. With #109413 merged, nothing in ESQL production depends on the core binary comparison classes anymore. This PR removes them to avoid the potential for confusion, and open the opportunity for merging the core `BinaryComparison` class with the `EsqlBinaryComparison` base class, which is now its only direct inheritor (work to be done in a future PR).
* rewrite in with EvaluatorMapper
Quick cleanup PR. With #109413 merged, nothing in ESQL production depends on the core binary comparison classes anymore. This PR removes them to avoid the potential for confusion, and open the opportunity for merging the core `BinaryComparison` class with the `EsqlBinaryComparison` base class, which is now its only direct inheritor (work to be done in a future PR).
* rewrite in with EvaluatorMapper
Quick cleanup PR. With #109413 merged, nothing in ESQL production depends on the core binary comparison classes anymore. This PR removes them to avoid the potential for confusion, and open the opportunity for merging the core `BinaryComparison` class with the `EsqlBinaryComparison` base class, which is now its only direct inheritor (work to be done in a future PR).
This is a subtask of #106679 to replace EvalMapper with EvaluatorMapper. There are multiple functions/predicates that use EvalMapper, this PR focus on the IN predicate.
The result of In predicate can be different whether the inlist has nulls in it or not. Multi-valued fields/expressions are not support by In predicate.