Hello,
We have defined some extra comparison functions for our users.
However, we’ve noticed that filter push-down (using `
CoreRules.FILTER_INTO_JOIN`) does not occur when the operands to the functions
come from the opposite side of an outer join (i.e. from the right side of a
left outer join,
Hi Ian,
I did not have time to dig more into your question (not very familiar with
the way you register functions), but for RuleEventLogger you might want to
check these slides (9 to 12 for how to activate it, the rest 15 to 23 on
how to read the output):
https://www.slideshare.net/StamatisZampetak
Hi Ian,
FilterJoinRule[1] is designed to not push filters to null-generating
side of Join, it has nothing to do with your custom UDF.
[1]
https://github.com/apache/calcite/blob/2bf1e7b2e8596a61b5ac19aa7bebb9910c4eea94/core/src/main/java/org/apache/calcite/rel/rules/FilterJoinRule.java#L111-L125
I wanted to figure out whether the transformation that you want is valid. Let’s
convert your query
select T1.id, T2.id
from T1 left join T2 on T1.id = T2.C201
where test(T1.id)
into one of the same shape:
select d.deptno, e.empno
from dept as d left join emp as e on d.deptno = e.deptn
Hi Benchao,
If that’s the case, then why are filters with non-custom operators pushed down?
For example: https://pastebin.com/raw/aPLnHMaS
Here I use `table.id = 1`,where `table` comes from the null-generating side of
the join.
Filter push down occurs, but only when FILTER_INTO_JOIN is enabled.
-
Hi Benchao,
Looking at this closer, I think I see what you mean.
The distinguishing factor here is that the Policy [1] for the EQUALS operator
is ANY, which is used in Strong.isNull to check if any of the operands can be
null (which is true when above an outer join), which allows
RelOptUtil.simp
