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)
