[jira] [Created] (CALCITE-5200) FILTER_INTO_JOIN rule in RelOptMaterializations is too "smart"

["Steven Talbot (Jira)" <ji...@apache.org>]

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)