Thomas Rebele created CALCITE-3977: -------------------------------------- Summary: RelDecorrelator produces incorrect plans if the input plan contains field accesses Key: CALCITE-3977 URL: https://issues.apache.org/jira/browse/CALCITE-3977 Project: Calcite Issue Type: Bug Reporter: Thomas Rebele
The RelCorrelator seems to have problems with some plans that contain a field access (probably a RexFieldAccess, but I haven't looked further into it). In this ticket there's a filter on *$cor0.birthPlace.city*. Here the complete plan: {code:java} before decorrelate LogicalCorrelate(correlation=[$cor0], joinType=[left], requiredColumns=[{}]) LogicalTableScan(table=[[bookstore, authors]]) LogicalFilter(condition=[=('Munich', $cor0.birthPlace.city)]) LogicalTableScan(table=[[bookstore, authors]]) after decorrelate LogicalJoin(condition=[=($2, $8)], joinType=[left]) LogicalTableScan(table=[[bookstore, authors]]) LogicalJoin(condition=[true], joinType=[inner]) LogicalFilter(condition=[=('Munich', $cor0.birthPlace.city)]) LogicalTableScan(table=[[bookstore, authors]]) LogicalAggregate(group=[{0}]) LogicalProject(birthPlace=[$2]) LogicalTableScan(table=[[bookstore, authors]]) {code} There seem to be two problems: * The LogicalCorrelate has been removed, but the $cor0.birthPlace.city is still in the filter condition. * The inner join does not seem to be necessary. If it is, could somebody explain, why? -- This message was sent by Atlassian Jira (v8.3.4#803005)