Ruben Q L created CALCITE-3585: ---------------------------------- Summary: Deprecate EnumerableJoinRule in favor of EnumerableHashJoinRule + EnumerableNestedLoopJoinRule Key: CALCITE-3585 URL: https://issues.apache.org/jira/browse/CALCITE-3585 Project: Calcite Issue Type: Task Reporter: Ruben Q L
As of today EnumerableJoinRule transforms a LogicalJoin into EnumerableConvention by producing two types of join operators: - EnumerableHashJoin: if the join condition is totally or partially an equi-join - EnumerableNestedLoopJoin: otherwise, i.e. if the join condition is completely a non-equi-join This distinction has its cause in the original implementation of EnumerableHashJoin, which only supported equi-join. However, with the implementation of CALCITE-2973, now EnumerableHashJoin supports all type of conditions, not just equi-join, so EnumerableHashJoin can be generated systematically. Moreover, with the implementation of CALCITE-3576, which allows FilterJoinRule to be applied in EnumerableConvention, the HashJoin vs NestedLoopJoin distinction in EnumerableJoinRule can be "flawed". Let us considered the following plan: {code} -- Select * FROM emp, dept WHERE emp.deptId = dept.id Filter (condition: emp.deptId = dept.id) Join (condition: true) Scan (table: emp) Scan (table: dept) {code} In this case (non-equi join), an EnumerableNestedLoopJoin would be created; but then FilterJoinRule could be applied, inserting the filter as a join condition, and ending up with an equi-join, "wrongly" implemented as an EnumerableNestedLoopJoin. For these reasons, and since EnumerableHashJoin and EnumerableNestedLoopJoin can now fully support all types of conditions, it could be better to deprecated EnumerableJoinRule and create instead two rules: - EnumerableHashJoinRule, which always creates an EnumerableHashJoin - EnumerableNestedLoopJoinRule, which always creates an EnumerableNestedLoopJoin -- This message was sent by Atlassian Jira (v8.3.4#803005)