[
https://issues.apache.org/jira/browse/CALCITE-3977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17107612#comment-17107612
]
Julian Hyde commented on CALCITE-3977:
--------------------------------------
[~zabetak] is right. Flattening is one option. Flattening was attractive
because it made the RPC layer easier. But it leaves a trail of havoc in the
planning process, so we're moving away from it.
If I recall correctly {{CorrelationId}} refers to a table alias in some FROM
clause in a query that encloses the current sub-query. In which case we could
add a {{rowType}} field to it. The {{int field}} field is too limiting - you
you may need a path, say the 3rd field inside the 2nd field. I think it would
make sense to change the type of {{field}} to {{RexNode}}. Today's {{field =
2}} would become {{RexInputRef(2)}} but you could also say things like
{{RexFieldAccess(RexInputRef(2), 3)}}. The {{RexInputRef}} would be relative to
the new {{rowType}} field in {{CorrelationId}}.
> RelDecorrelator does not resolve correlation variable with field accesses
> -------------------------------------------------------------------------
>
> Key: CALCITE-3977
> URL: https://issues.apache.org/jira/browse/CALCITE-3977
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.22.0
> Reporter: Thomas Rebele
> Priority: Major
> Attachments: Calcite3977.java
>
>
> 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)
