siddharthteotia commented on code in PR #9909:
URL: https://github.com/apache/pinot/pull/9909#discussion_r1044866861


##########
pinot-query-runtime/src/main/java/org/apache/pinot/query/runtime/operator/operands/TransformOperand.java:
##########
@@ -18,26 +18,123 @@
  */
 package org.apache.pinot.query.runtime.operator.operands;
 
+
+import com.google.common.base.Preconditions;
+import java.util.List;
 import org.apache.pinot.common.utils.DataSchema;
 import org.apache.pinot.query.planner.logical.RexExpression;
+import org.apache.pinot.query.runtime.operator.utils.FunctionInvokeUtils;
+import org.apache.pinot.query.runtime.operator.utils.OperatorUtils;
 
 
 public abstract class TransformOperand {
   protected String _resultName;
   protected DataSchema.ColumnDataType _resultType;
 
-  public static TransformOperand toTransformOperand(RexExpression 
rexExpression, DataSchema dataSchema) {
+  public static TransformOperand toTransformOperand(RexExpression 
rexExpression, DataSchema inputDataSchema) {
     if (rexExpression instanceof RexExpression.InputRef) {
-      return new ReferenceOperand((RexExpression.InputRef) rexExpression, 
dataSchema);
+      return new ReferenceOperand((RexExpression.InputRef) rexExpression, 
inputDataSchema);
     } else if (rexExpression instanceof RexExpression.FunctionCall) {
-      return new FunctionOperand((RexExpression.FunctionCall) rexExpression, 
dataSchema);
+      return toTransformOperand((RexExpression.FunctionCall) rexExpression, 
inputDataSchema);
     } else if (rexExpression instanceof RexExpression.Literal) {
       return new LiteralOperand((RexExpression.Literal) rexExpression);
     } else {
       throw new UnsupportedOperationException("Unsupported RexExpression: " + 
rexExpression);
     }
   }
 
+  @SuppressWarnings({"ConstantConditions", "rawtypes", "unchecked"})
+  private static TransformOperand 
toTransformOperand(RexExpression.FunctionCall functionCall,
+      DataSchema inputDataSchema) {
+    final List<RexExpression> functionOperands = 
functionCall.getFunctionOperands();
+    int operandSize = functionOperands.size();
+    switch 
(OperatorUtils.canonicalizeFunctionName(functionCall.getFunctionName())) {
+      case "AND":
+        Preconditions.checkState(operandSize >= 2, "AND takes >=2 argument, 
passed in argument size:" + operandSize);
+        return new FilterOperand.And(functionOperands, inputDataSchema);
+      case "OR":
+        Preconditions.checkState(operandSize >= 2, "OR takes >=2 argument, 
passed in argument size:" + operandSize);
+        return new FilterOperand.Or(functionOperands, inputDataSchema);
+      case "NOT":
+        Preconditions.checkState(operandSize == 1, "NOT takes one argument, 
passed in argument size:" + operandSize);
+        return new FilterOperand.Not(functionOperands.get(0), inputDataSchema);
+      case "equals":
+        return new FilterOperand.Predicate(functionOperands, inputDataSchema) {
+          @Override
+          public Boolean apply(Object[] row) {
+            if (_requireCasting) {
+              return ((Comparable) 
FunctionInvokeUtils.convert(_lhs.apply(row), _commonCastType)).compareTo(
+                  FunctionInvokeUtils.convert(_rhs.apply(row), 
_commonCastType)) == 0;
+            } else {
+              return ((Comparable) _lhs.apply(row)).compareTo(_rhs.apply(row)) 
== 0;
+            }
+          }
+        };
+      case "notEquals":
+        return new FilterOperand.Predicate(functionOperands, inputDataSchema) {
+          @Override
+          public Boolean apply(Object[] row) {
+            if (_requireCasting) {

Review Comment:
   I think apart from this branch and chain of function calls, we will not have 
any overhead between execution that requires cast v/s the one that doesn't ?
   
   Postgres says -- `There should be no extra overhead in the parser or 
executor if a query does not need implicit type conversion. That is, if a query 
is well-formed and the types already match, then the query should execute 
without spending extra time in the parser and without introducing unnecessary 
implicit conversion calls in the query.`
   
   It is very likely they are doing r`untime query specific codegen` to be able 
to bypass excessive function calls, branches etc. I don't think we want to get 
there anytime but something we can think about later if this becomes super 
expensive for complex queries. 



-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to