Steven Talbot created CALCITE-5200:
--------------------------------------
Summary: FILTER_INTO_JOIN rule in RelOptMaterializations is too
"smart"
Key: CALCITE-5200
URL: https://issues.apache.org/jira/browse/CALCITE-5200
Project: Calcite
Issue Type: Bug
Reporter: Steven Talbot
Specifically, when it fires (using the names in
"RelOptMaterialization.substitute") if the "root" has a filter on the right
table of a LEFT join, and "materialization" does not, then the rule turns the
left join into an INNER join in "root", which then fails to match
"materialization", preventing valid optimization. ("valid" in the sense that
the optimization works either without the filter or with an inner join).
I'm lacking the setup to write a test at the moment, and I don't see a test
file that targets RelOptMaterializations specifically, but something like
{noformat}
RelNode root = relBuilder.scan(emp)
.scan(dept)
.join(JoinType.LEFT, "deptNo")
.filter(relBuilder.equals(relBuilder.field(2, "dept", "deptNo"),
relBuilder.literal(1))
.project(<some_cols>)
.aggregate(<however>)
RelNode materialization = relBuilder.scan(emp)
.scan(dept)
.join(JoinType.LEFT, "deptNo")
.project(<some_cols>)
.aggregate(<however>){noformat}
The "smart" config in the FilterIntoJoin rule is what does this rewrite, and I
would contend that we should use the "dumb" config instead for
RelOptMaterializations, because for the purposes of getting a match the rule
should change exactly what it needs to change and nothing else.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
