[
https://issues.apache.org/jira/browse/CALCITE-3585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L updated CALCITE-3585:
-------------------------------
Description:
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 could 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
was:
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
> 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
> Priority: Minor
>
> 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 could 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)
