Hello,
In many research papers and database books the equi join is defined as an
equality operator between two attribute names (columns etc.) which more or
less corresponds to the current definition in Calcite thus I don't see an
obvious reason to change this definition. If necessary, there could
Danny,
I have seen the full picture and I have actually changed mind:
If I am not mistaken, currently the way to make your example (and mine) to
work as an EquiJoin is using intermediate projections (so that RexCall
/ RexFieldAccess "becomes" RexInputRef):
Select A.a, B.b from A join B on
Thx Ruben, the issue really answer my questions, I encounter this when dong
CALCITE-2969, when I refactor SemiJoinRule, I think not only RexFieldAccess,
any RexCall should fit into this case, only if the RexCall function is
deterministic, what do you think ?
Best,
Danny Chan
在 2019年4月15日 +0800
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
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]
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,
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)
