For the example I gave, the join condition is push down with RelOptUtil.pushDownJoinConditions(), but when we new a join info [1], we only decide if the join is EquiJoin if all the operands of operator <=> is inputRef, which is the question i ask here.
[1] https://github.com/apache/calcite/blob/9538374e8fae5cec7d6f7b270850f5dfb4c1fc06/core/src/main/java/org/apache/calcite/plan/RelOptUtil.java#L1435 Best, Danny Chan 在 2019年4月15日 +0800 PM7:25，Xiening Dai <[email protected]>，写道： > 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 >
