rohangarg commented on a change in pull request #11434:
URL: https://github.com/apache/druid/pull/11434#discussion_r668793387
##########
File path:
sql/src/main/java/org/apache/druid/sql/calcite/rule/DruidJoinRule.java
##########
@@ -283,7 +283,8 @@ static boolean canHandleCondition(final RexNode condition,
final RelDataType lef
private static boolean isLeftExpression(final RexNode rexNode, final int
numLeftFields)
{
- return
ImmutableBitSet.range(numLeftFields).contains(RelOptUtil.InputFinder.bits(rexNode));
+ ImmutableBitSet inputBitSet = RelOptUtil.InputFinder.bits(rexNode);
+ return !inputBitSet.isEmpty() &&
ImmutableBitSet.range(numLeftFields).contains(inputBitSet);
Review comment:
I added the empty check since without this (with the new changes), the
`testFilterAndGroupByLookupUsingJoinOperator` was failing with
`org.apache.druid.java.util.common.IAE: Cannot join lookup with condition
referring to non-key column: (("dim2" == "j0.k") && ('xa' == "j0.v"))
at
org.apache.druid.segment.join.lookup.LookupJoinMatcher.create(LookupJoinMatcher.java:201)`.
The reason was that the left join in the query was getting converted to
inner join with condition `foo.dim2 = lookyloo.k && lookyloo.v = 'xa'` which
the lookup join matcher can't handle.
But now when I think of it more, I think this could generate sup-optimal
plans for the IndexedTableMatcher which doesn't have such strict checks on the
equi conditions.
--
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]
