I think that simplification should been made on join conditions - I've done a
quick check; and it seems to be working for me.
I suspected that it will be either a missing call to RexSimplify for some reason - or it is added by a forced return type correction: IIRC there are some cases in which the
RexNode type should retained after simplification.
Is this reproducible on current master; could you share a testcase?
On 3/24/20 7:28 AM, Shuo Cheng wrote:
Hi, Julian, That's what we do as a workaround way. we remove CAST which are
only widening nullability as what CALCITE-2695 does before applying
hash-join/sort-merge-join rule, such that equiv predicate can be split
out. I'm not sure whether it's properly for Calcite to do the 'convert
back' job, for example, simplify the join condition when create a Join; Or
maybe let other systems what use Calcite to do the "convert back" job as an
optimization? What do you think?
On Tue, Mar 24, 2020 at 2:04 PM Julian Hyde <jhyde.apa...@gmail.com> wrote:
Or convert it back to a not-nullable BOOLEAN? The join condition treats
UNKNOWN the same as FALSE, and besides UNKNOWN will never occur, so the
conditions with and without the CAST are equivalent.
On Mar 23, 2020, at 9:34 PM, Shuo Cheng <njucs...@gmail.com> wrote:
Considering the Join condition 'CAST(IS_NOT_DISTINCT_FROM($1, $2),
BOOLEAN)', which cast the non-nullable BOOLEAN to nullable BOOLEAN,
can not split out equiv predicate, thus some join operation like hash
/ sort merge join may not be used. Maybe we can
expand RelOptUtil#splitJoinCondition to support this scenario?