soumyakanti3578 commented on code in PR #5196:
URL: https://github.com/apache/hive/pull/5196#discussion_r1936378364
##########
ql/src/java/org/apache/hadoop/hive/ql/optimizer/calcite/translator/ASTConverter.java:
##########
@@ -1078,6 +1098,36 @@ public ASTNode visitCall(RexCall call) {
// proceed correctly if we just ignore the <time_unit>
astNodeLst.add(call.operands.get(1).accept(this));
break;
+ case SEARCH:
+ ASTNode astNode = call.getOperands().get(0).accept(this);
+ astNodeLst.add(astNode);
+ RexLiteral literal = (RexLiteral) call.operands.get(1);
+ Sarg<?> sarg = Objects.requireNonNull(literal.getValueAs(Sarg.class),
"Sarg");
+ int minOrClauses =
SessionState.getSessionConf().getIntVar(HiveConf.ConfVars.HIVE_POINT_LOOKUP_OPTIMIZER_MIN);
Review Comment:
If we don't use this property we will generate sql like `x IN (1)`. Also
there can be test changes and differences. Not sure if keeping this will
heavily impact performance as it is just an int comparison and we only really
convert to `OR` when the number of points is less than
`HIVE_POINT_LOOKUP_OPTIMIZER_MIN` whose default value is 2, which is pretty
low. Usually there will be at least 2 arguments in an `IN` operator, so we will
rarely hit this.
On the other hand, if someone explicitly sets a higher value for the
property and we still generate `IN`s when the number of arguments are lower,
that might look like a bad implementation or a bug.
So I am not sure what is better too. But I do agree that there maybe a small
decrease in performance.
--
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: gitbox-unsubscr...@hive.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: gitbox-unsubscr...@hive.apache.org
For additional commands, e-mail: gitbox-h...@hive.apache.org
