suneet-s commented on a change in pull request #10401:
URL: https://github.com/apache/druid/pull/10401#discussion_r493661502
##########
File path: core/src/main/java/org/apache/druid/math/expr/ApplyFunction.java
##########
@@ -51,11 +51,26 @@
*/
String name();
+ /**
+ * Check if an apply function can be 'vectorized', for a given {@link
LambdaExpr} and set of {@link Expr} inputs.
+ * If this method returns true, {@link #asVectorProcessor} is expected to
produce a {@link ExprVectorProcessor} which
+ * can evaluate values in batches to use with vectorized query engines.
+ *
+ * @see Expr#canVectorize(Expr.InputBindingTypes)
+ * @see Function#canVectorize(Expr.InputBindingTypes, List)
+ */
default boolean canVectorize(Expr.InputBindingTypes inputTypes, Expr lambda,
List<Expr> args)
{
return false;
}
+ /**
+ * Builds a 'vectorized' function expression processor, that can build
vectorized processors for its input values
+ * using {@link Expr#buildVectorized}, for use in vectorized query engines.
+ *
Review comment:
It would be nice to explain the relationship between `<T>` and
`getOutputType` here and in similar docs. Specifically I'm wondering about as
an implementor of the interface, do I need to ensure that the types are always
the same? What happens if the types don't match? Is there something in the
system that will throw an exception? or will be slow, because of some implicit
casting somewhere else?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
