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 <[email protected]> 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. > > Julian > > > On Mar 23, 2020, at 9:34 PM, Shuo Cheng <[email protected]> wrote: > > > > Hi all, > > > > Considering the Join condition 'CAST(IS_NOT_DISTINCT_FROM($1, $2), > > BOOLEAN)', which cast the non-nullable BOOLEAN to nullable BOOLEAN, > Calcite > > can not split out equiv predicate, thus some join operation like hash > join > > / sort merge join may not be used. Maybe we can > > expand RelOptUtil#splitJoinCondition to support this scenario? >
