[
https://issues.apache.org/jira/browse/CALCITE-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17511415#comment-17511415
]
Julian Hyde commented on CALCITE-5061:
--------------------------------------
Unless {{RelFieldTrimmer}} is fundamentally broken it would be better to evolve
the current algorithm (and to continue to pass all of the current tests) than
to start from scratch.
One of the limitations of {{RelFieldTrimmer}} (not its fault) is the fact that
it is invoked only once. It needs to modify the whole tree (because unlike
rules, it changes the output type of {{RelNode}} instances) and so invoking it
more than once is (we assume) cost prohibitive.
That might limit what it can do. Perhaps you only discover that a
UNION-distinct can be converted to a UNION-all half way through planning. That
would allow you to trim more fields. But the time for field trimming has
passed. (Just a hypothesis for what is going on in CALCITE-5051.)
> 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
> Fix For: 1.31.0
>
>
> 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.1#820001)
