[FLINK-39763][table] Allow inferring constants with IS NOT DISTINCT FROM#28256
Conversation
| <![CDATA[ | ||
| Calc(select=[a, b, CAST(2 AS INTEGER) AS d, e]) | ||
| +- MultipleInput(readOrder=[0,1], members=[\nHashJoin(joinType=[InnerJoin], where=[((a = d) AND (b = e))], select=[a, b, d, e], isBroadcast=[true], build=[right])\n:- HashAggregate(isMerge=[true], groupBy=[a], select=[a, Final_COUNT(count$0) AS b])\n: +- [#2] Exchange(distribution=[hash[a]])\n+- [#1] Exchange(distribution=[broadcast])\n]) | ||
| Calc(select=[CAST(2 AS INTEGER) AS a, b, CAST(2 AS INTEGER) AS d, e]) |
There was a problem hiding this comment.
the constant pulled up
| join | ||
| (select d, count(e) as e from MyTable2 group by d) | ||
| on a = d and b = e and d = 2 and b = 1 | ||
| ]]> |
There was a problem hiding this comment.
here and for other joins (except for NestedLoop)
now Calcite is able to understand that a == 2 and e == 1
after that it is able to push down these values to corresponding table sources
as a result non nested loop join will fail as there is only true in join condition.
when all joins are available then NestedLoop will be selected, there is also e2e case in DecimalITCase in this PR
|
Do we need/want to add a test for |
| tEnv.getConfig | ||
| .set(ExecutionConfigOptions.TABLE_EXEC_DISABLED_OPERATORS, "HashJoin, NestedLoopJoin") |
There was a problem hiding this comment.
same reason as explained above #28256 (comment)
| @@ -79,10 +79,7 @@ | |||
| * because of current Calcite way of inferring constants from IS NOT DISTINCT FROM clashes with | |||
| * filter push down. | |||
There was a problem hiding this comment.
Seems like this comment needs to be updated?
There was a problem hiding this comment.
makes sense, updated
if you mean |
What is the purpose of the change
The PRs enables Calcite's optimization for inferring constants https://issues.apache.org/jira/browse/CALCITE-5336
Brief change log
RexUtil
Verifying this change
Existing tests and updated tests
Does this pull request potentially affect one of the following parts:
@Public(Evolving): (no)Documentation
Was generative AI tooling used to co-author this PR?