[
https://issues.apache.org/jira/browse/CALCITE-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17534778#comment-17534778
]
Thomas Rebele commented on CALCITE-5061:
----------------------------------------
The proposed changes have been developed from scratch. I re-used the code
blocks of {{{}RelFieldTrimmer{}}}, where it was possible. The most notable
change is the split of the logic for calculating which fields are used by a
node
({{{}[RelFieldUsageVisitor|https://github.com/thomasrebele/calcite/blob/CALCITE-5061/core/src/main/java/org/apache/calcite/util/RelFieldUsageVisitor.java]{}}}),
and the actual trimming logic
({{{}[RelFieldTrimmerAlternative|https://github.com/thomasrebele/calcite/blob/CALCITE-5061/core/src/main/java/org/apache/calcite/util/RelFieldTrimmerAlternative.java]{}}}).
A hypothetical use-case scenario: The {{RelFieldUsageVisitor}} analyzes every
query, notes which table columns contribute to the result, and once in a while
logs the "hot columns". The DB admin could then use the info for optimization
(e.g. by moving these columns to a faster disk or in-memory).
> 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.7#820007)
