Thomas Rebele created CALCITE-3978:
--------------------------------------
Summary: RelDecorrelator on a plan with field accesses does not
update field indices when adding a projection
Key: CALCITE-3978
URL: https://issues.apache.org/jira/browse/CALCITE-3978
Project: Calcite
Issue Type: Bug
Reporter: Thomas Rebele
RelDecorrelate introduces a projection (or a new field on an existing
projection) within the first input of a join node, without shifting the field
indices accessing the second input:
Schema:
* table1
** F_1 _(varchar)_
* table2
** F_2
*** F_2_SUB _(varchar)_
* table3
** F_3
*** F_3_SUB _(varchar)_
{code:java}
before decorrelate
LogicalCorrelate(correlation=[$cor0], joinType=[inner], requiredColumns=[{}])
LogicalTableScan(table=[[TABLE1]])
LogicalJoin(condition=[=($0.F_2_SUB, $1.F_3_SUB)], joinType=[inner]) <--- (1)
LogicalFilter(condition=[=($cor0.F_1, $0.F_2_SUB)])
LogicalTableScan(table=[[TABLE2]])
LogicalTableScan(table=[[TABLE3]])
after decorrelate
LogicalJoin(condition=[=($0, $2)], joinType=[inner])
LogicalTableScan(table=[[TABLE1]])
LogicalJoin(condition=[true], joinType=[inner]) <----------+--- (2)
LogicalFilter(condition=[=($0.F_2_SUB, $1.F_3_SUB)]) <---/
LogicalFilter(condition=[=($1, $0.F_2_SUB)])
LogicalProject(F_2=[$0], $f1=[$0.F_2_SUB]) <--- (3)
LogicalTableScan(table=[[TABLE2]])
LogicalTableScan(table=[[TABLE3]])
{code}
A project has been introduced at (3), which adds a field to the first input of
the join (1)/(2). However, the join condition needs to be fixed. The $1.F_3_SUB
at (1) should be $2.F_3_SUB at (2). That's probably the reason why the
condition has been moved to a filter on the first input, as it targets
(wrongly) only the first input of the join.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
