Danny, In the context of https://issues.apache.org/jira/browse/CALCITE-2898, a discussion about this topic was started. In that ticket I pointed out that Calcite does not recognize "RexFieldAccess = RexInputRef" as an EquiJoin condition (even though the RexFieldAccess itself is referencing a RexInputRef); which is somewhat similar to the situation that you propose "RexCall = RexInputRef". According to Julian Hyde's comment on that ticket: *'For our purposes, an equi-join is "field = field", not "expression = field". Even if that expression is a reference to sub-field'. *However, I agree with you and maybe this definition should be reviewed (I believe your example and my example should be valid cases of EquiJoin), but possibly this will break some pieces of the current code, so the modification might not be straightforward.
Best, Ruben Le lun. 15 avr. 2019 à 13:25, Xiening Dai <[email protected]> a écrit : > I think Calcite always pushes down equal join conditions. In > SqlToRelConverter.createJoin(), before ruction returns, it calls > RelOptUtil.pushDownJoinConditions(). So in your example, the cast > expression will be pushed down and it will still be an equal join. > > > On Apr 15, 2019, at 5:40 PM, Yuzhao Chen <[email protected]> wrote: > > > > If we checkout the java doc for Calcite EuqiJoin, there is definition > for it: > >> for any join whose condition is based on column equality > > > > But what about if there are function calls in the equi condition > operands ? For example: > > Should we consider > > > > Select A.a, B.b from A join B on cast(A.a as int) = B.b > > > > as an equi join ? > > > > Now Calcite think it is not, which I think will lost some possibilities > for sql plan promotion, e.g. join condition push down. > > > > Best, > > Danny Chan > >
