You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Ruben Quesada Lopez (JIRA)" <ji...@apache.org> on 2019/03/07 08:35:00 UTC

[jira] [Comment Edited] (CALCITE-2898) RelOptUtil#splitJoinCondition must consider RexFieldAccess referencing RexInputRef

    [ https://issues.apache.org/jira/browse/CALCITE-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16786514#comment-16786514 ] 

Ruben Quesada Lopez edited comment on CALCITE-2898 at 3/7/19 8:34 AM:
----------------------------------------------------------------------

To provide a bit of context, I got into this issue while creating a semijoin involving a condition  "field = expression.field". In spite of the problem described in this ticket (condition not identified as equijoin), the semijoin is created fine by SemiJoinFactoryImpl:
{code:java}
  private static class SemiJoinFactoryImpl implements SemiJoinFactory {
    public RelNode createSemiJoin(RelNode left, RelNode right,
        RexNode condition) {
      final JoinInfo joinInfo = JoinInfo.of(left, right, condition);
      return SemiJoin.create(left, right,
        condition, joinInfo.leftKeys, joinInfo.rightKeys);
    }
  }
{code}

However, during the plan computation, SemiJoin#copy method is executed, which contains an assertion to verify that we are dealing with an equijoin:
{code:java}
  @Override public SemiJoin copy(RelTraitSet traitSet, RexNode condition,
      RelNode left, RelNode right, JoinRelType joinType, boolean semiJoinDone) {
    assert joinType == JoinRelType.INNER;
    final JoinInfo joinInfo = JoinInfo.of(left, right, condition);
    assert joinInfo.isEqui();  // !!! <= AssertionError
    return new SemiJoin(getCluster(), traitSet, left, right, condition,
        joinInfo.leftKeys, joinInfo.rightKeys);
  }
{code}

In my case, I got an AssertionError (joinInfo is not equijoin), but this seems to be a "false" error, because if I run my test with assertions disabled, it runs successfully: my semijoin with the condition $0 = $1.id returns the expected results.
Therefore, I believe either the assertion should be removed (if there is no assertion when we create the semijoin, I don't see why there should be one when copying it); or conditions like the one on my test should be detected as equijoin (as proposed in the PR).



was (Author: rubenql):
To provide a bit of context, I got into this issue while creating a semijoin involving an expression "field = expression.field". In spite of the problem described in this ticket (condition not idenfitifed as equijoin), the semijoin is created fine by SemiJoinFactoryImpl:
{code:java}
  private static class SemiJoinFactoryImpl implements SemiJoinFactory {
    public RelNode createSemiJoin(RelNode left, RelNode right,
        RexNode condition) {
      final JoinInfo joinInfo = JoinInfo.of(left, right, condition);
      return SemiJoin.create(left, right,
        condition, joinInfo.leftKeys, joinInfo.rightKeys);
    }
  }
{code}

However, during the plan computation, SemiJoin#copy method is executed, which contains an assertion to verify that we are dealing with an equijoin:
{code:java}
  @Override public SemiJoin copy(RelTraitSet traitSet, RexNode condition,
      RelNode left, RelNode right, JoinRelType joinType, boolean semiJoinDone) {
    assert joinType == JoinRelType.INNER;
    final JoinInfo joinInfo = JoinInfo.of(left, right, condition);
    assert joinInfo.isEqui();  // !!! <= AssertionError
    return new SemiJoin(getCluster(), traitSet, left, right, condition,
        joinInfo.leftKeys, joinInfo.rightKeys);
  }
{code}

In my case, I got an AssertionError (joinInfo is not equijoin), but this seems to be a "false" error, because if I run my test with assertions disabled, it runs successfully. So, I believe either the assertion should be removed (if there is no assertion when we create the semijoin, I don't see why there should be one when copying it); or conditions like the one on my tests should be detected as equijoin (as proposed in the PR).


> RelOptUtil#splitJoinCondition must consider RexFieldAccess referencing RexInputRef
> ----------------------------------------------------------------------------------
>
>                 Key: CALCITE-2898
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2898
>             Project: Calcite
>          Issue Type: Bug
>    Affects Versions: 1.18.0
>            Reporter: Ruben Quesada Lopez
>            Assignee: Ruben Quesada Lopez
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> {{RelOptUtil#splitJoinCondition}} "Splits out the equi-join components of a join condition, and returns what's left (remaining join filters that are not equijoins)". This works fine in case of RexInputRef operands in the condition (e.g. $0 = $1), but if any of the operands is a RexFieldAccess referencing a RexInputRef (e.g. $0 = $1.id), then the condition will NOT be detected as an equi-join and will be returned as if it were a non-equijoin. 
> This can lead to undesired consequences, e.g {{JoinInfo#of}} would return a NonEquiJoinInfo object instead of an EquiJoinInfo object, which can generate problems if, for example, we are creating a SemiJoin (which requires an EquiJoinInfo object)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)