asolimando commented on a change in pull request #2839:
URL: https://github.com/apache/hive/pull/2839#discussion_r761801075
##########
File path:
ql/src/java/org/apache/hadoop/hive/ql/optimizer/calcite/rules/HiveFilterProjectTransposeRule.java
##########
@@ -339,6 +339,11 @@ private void check(Filter filter) {
final RexNode filterCondition = simplify.simplify(filter.getCondition());
final Set<Integer> inputRefs =
HiveCalciteUtil.getInputRefs(newCondition);
+ // if the new IS NOT NULL has no input ref, there is redundancy here,
bail out
+ if (inputRefs.isEmpty()) {
Review comment:
This method is invoked only for `IS NOT NULL` calls, so we can't have
other kind of calls here.
This said, I agree about trying to use more `RexSimplify` with `uAF` mode
when we create/modify predicates in our CBO rules,
https://github.com/apache/hive/pull/2840 is heading into that direction
for`HiveJoinPushTransitivePredicatesRule`, for instance.
In that case we end up in a loop pulling and pushing down the same predicate
all over again, which can be avoided with simplification. On top of that, we
might even unlock more optimization opportunities if we have consistent
simplification/normalization. In the past I have seen that some Hive rules
taken from Calcite are missing `RexSimplify.simplify` where in Calcite this has
been added later, it's a pity I can't find the example right now.
In summary, I agree to open a separate Jira ticket for revising our
normalization/simplification strategy in CBO rules.
--
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]
