[ 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)