[
https://issues.apache.org/jira/browse/CALCITE-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17535100#comment-17535100
]
Julian Hyde commented on CALCITE-5061:
--------------------------------------
It seems that there are two orthogonal problems here: the mechanism by which
the field usages are deduced, and the fact that the trimmer curtails its walk
over the tree when it encounters a {{RelNode}} whose fields are all used.
The former (deducing field usages) could be solved by {{RelFieldUsageVisitor}}
in a separate change. I'm not convinced it is a problem as such, although I
could be convinced that the new implementation is more efficient, and that the
field usage graph (column-level provenance) would be a useful form of metadata.
Can the latter problem (preventing the walk from being curtailed) be solved
without implementing the former? Or failing that, can it be solved in a
separate commit?
I want to separate them because I want to move in small steps. I would much
rather review evolutionary changes than do a rewrite and put all my trust in
the test suite.
> Improve recursive application of the field trimming
> ---------------------------------------------------
>
> Key: CALCITE-5061
> URL: https://issues.apache.org/jira/browse/CALCITE-5061
> Project: Calcite
> Issue Type: Improvement
> Reporter: Thomas Rebele
> Assignee: Thomas Rebele
> Priority: Major
>
> The RelFieldTrimmer has some shortcomings:
> * If the plan contains certain set ops (e.g., UNION(all=false)), even if the
> operator needs all fields for the correct result (CALCITE-3399), it may still
> make sense to apply the trimming to the children. See CALCITE-5051 for an
> example.
> * Same applies for a Sort with dynamic parameters in the fetch/offset, and
> RepeatUnions
> * The makeZeroLiteral logic in trimChildRestore(...) does not work for ARRAY
> / Java types.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
