The EnumerableXxxx RelNodes are algorithms. To be efficient, an algorithm makes particular assumptions (e.g. the condition is based on equality).
If there are limitations, over time we would like to remove those limitations, but we will probably do it by adding new algorithms, and therefore new EnumerableXxx classes. In https://issues.apache.org/jira/browse/CALCITE-2969 <https://issues.apache.org/jira/browse/CALCITE-2969> I see you are proposing to rename EnumerableJoin to EnumerableHashJoin, and similar renames. That is good. It makes clear the limitations of the current algorithm, and makes room for alternative algorithms. Julian > On Apr 22, 2019, at 6:08 AM, Yuzhao Chen <yuzhao....@gmail.com> wrote: > > EnumerableJoin EnumerableMergeJoin EnumerableSemiJoin all only support > equi-join condition[1], and there are some > rules that match EquiJoin specificly, like FilterJoinRule will not push > non-equi join predicates into the join condition[2], so what is the original > intention that these join enumetables only have equi-join implementation ? > > Do you think there is necessity to support non-join conditions for these > joins ? I just found that there is a PR to support a hash-theta-join for > theta join with equi-join condition[3]. > > > [1] > https://github.com/apache/calcite/blob/ee83efd360793ef4201f4cdfc2af8d837b76ca69/linq4j/src/main/java/org/apache/calcite/linq4j/EnumerableDefaults.java#L1125 > [2] > https://github.com/apache/calcite/blob/ee83efd360793ef4201f4cdfc2af8d837b76ca69/core/src/main/java/org/apache/calcite/rel/rules/FilterJoinRule.java#L165 > [3] https://github.com/apache/calcite/pull/1156 > > Best, > Danny Chan
