[
https://issues.apache.org/jira/browse/CALCITE-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17511471#comment-17511471
]
Julian Hyde commented on CALCITE-5051:
--------------------------------------
Thanks for confirming that CALCITE-3399 is the culprit. That gives us a path
forward to solve this issue.
I agree that we should call trimFields on the whole tree, even if an
intermediate node cannot be trimmed for some reason. I believe that is what
[~thomas.rebele] is planning to do in CALCITE-5061.
But perhaps there is a simpler fix. The fix for 3399 was to not call trim on
the set operation. I believe the fix should have been to continue to call trim
on set operations, but the set operator should ignore the {{fieldsUsed}} mask
and continue to return all fields. In {{RelFieldTrimmer}}, {{fieldsUsed}} is
already advisory -- the handler for the particular {{RelNode}} type is at
liberty to return any superset of {{fieldsUsed}} that it chooses, in whatever
order.
> UNION query plan prevents projection push down
> ----------------------------------------------
>
> Key: CALCITE-5051
> URL: https://issues.apache.org/jira/browse/CALCITE-5051
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.29.0
> Reporter: Zachary Gramana
> Priority: Major
>
> As a user with a custom Calcite adapter that does push down, I should be able
> to run a UNION query of statements containing joins and still get the benefit
> of projection push down.
> Given a query such as:
> {code:sql}
> SELECT Id
> FROM MySchema.t1
> UNION
> SELECT t3.Id
> FROM MySchema.t2
> JOIN MySchema.t3 ON (t3.Id = t2.t3_Id)
> {code}
> I expect a resulting query plan that looks like:
> {code:lua}
> EnumerableUnion(all=[true])
> MyEnumerableConverter
> MyProject(Id=[$0])
> MyTableScan(table=[[MySchema, t1]])
> EnumerableCalc(expr#0..1=[{inputs}], Id=[$t1])
> EnumerableMergeJoin(condition=[=($0, $1)], joinType=[inner])
> EnumerableSort(sort0=[$0], dir0=[ASC])
> EnumerableCalc(expr#0..100=[{inputs}], expr#101=[CAST($t1):BIGINT NOT
> NULL], t3_Id0=[$t101])
> MyEnumerableConverter
> MyTableScan(table=[[MySchema, t2]])
> EnumerableSort(sort0=[$0], dir0=[ASC])
> MyEnumerableConverter
> MyProject(Id=[$0])
> MyTableScan(table=[[MySchema, t3]])
> {code}
> But instead I observed:
> {code:java}
> EnumerableUnion(all=[false])
> MyEnumerableConverter
> MyProject(Id=[$0])
> MyTableScan(table=[[MySchema, t1]])
> EnumerableCalc(expr#0..251=[{inputs}], Id=[$t102])
> EnumerableMergeJoin(condition=[=($101, $102)], joinType=[inner])
> EnumerableSort(sort0=[$101], dir0=[ASC])
> EnumerableCalc(expr#0..100=[{inputs}], expr#101=[CAST($t1):BIGINT NOT
> NULL], proj#0..101=[{exprs}])
> MyEnumerableConverter
> MyTableScan(table=[[MySchema, t2]])
> EnumerableSort(sort0=[$0], dir0=[ASC])
> MyEnumerableConverter
> MyTableScan(table=[[MySchema, t3]])
> {code}
> Note that:
> # The {{EnumerableCalc}} node applied to the {{EnumerableMergeJoin}} goes
> from taking 1 expected input field to taking 251 input fields
> # The {{MyProject}} node expected to be applied to
> {{MyTableScan(table=[[MySchema, t3]])}} is missing from the observed plan
> # Issue was observed after upgrading from 1.24 to 1.29, so may affect one or
> more intervening releases
> # PR containing reproducing unit test:
> https://github.com/apache/calcite/pull/2747
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
