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)
