[jira] [Comment Edited] (CALCITE-7059) Generalize RelFieldTrimmer to handle plans with arbitrary operators

["Julian Hyde (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-7059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17980142#comment-17980142 ] 

Julian Hyde edited comment on CALCITE-7059 at 6/17/25 3:42 PM:
---------------------------------------------------------------

Regarding {{RelBuilder}}. I suspect it is still the least-bad option. We have never really solved the problem of "making factories pluggable". We tried adding "copy" methods to each family of RelNodes, and they would frequently fail to populate traits correctly.

You can take a {{RelBuilder}} and momentarily swap its factory-set for another factory-set of a different convention. I think that's the way to go.

If you pursue your plan to use {{copy}} methods I'm sure you can make it work eventually, but the investment you make will not improve quality for other uses. In open source projects people to tend to think of resources having infinite cost (because you don't know how to fix a problem) or zero cost (because someone else is paying) but I prefer to think of resources as having a high finite cost and therefore focus development resources on a few key pieces of architecture - in this case, {{RelBuilder}}.


was (Author: julianhyde):
Regarding {{RelBuilder}}. I suspect it is still the least-bad option. We have never really solved the problem of "making factories pluggable". We tried adding "copy" methods to each family of RelNodes, and they would frequently fail to populate traits correctly.

You can take a {{RelBuilder}} and momentarily swap its factory-set for another factory-set of a different convention. I think that's the way to go.

> Generalize RelFieldTrimmer to handle plans with arbitrary operators
> -------------------------------------------------------------------
>
>                 Key: CALCITE-7059
>                 URL: https://issues.apache.org/jira/browse/CALCITE-7059
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.40.0
>            Reporter: Stamatis Zampetakis
>            Priority: Major
>
> Currently the [RelFieldTrimmer|https://github.com/apache/calcite/blob/597b1fd54fe5b8586525aed2bc4518ca54a25523/core/src/main/java/org/apache/calcite/sql2rel/RelFieldTrimmer.java] class is mostly tailored to handle plans using the built-in {{LogicalXx}} operators. Still there are many projects that have their own flavor of "logical" operators, which do not differ much from the built-in when it comes to field trimming, and are forced to extend or copy the trimmer code in order to use it.
> To further expand the usage of the trimmer and minimize unnecessary extensions we could envision the following enhancements.
> *Refactor references/usages of LogicalXx operators*
> In most cases a {{Logical}} operator is extending another more abstract one so we could favor the use of the abstract one in every place where a logical one is used.
> *Use {{RelNode#copy}} instead of the {{RelBuilder}} to create the new (trimmed) expressions*
> The trimmer currently makes use of a {{RelBuilder}} in various places to create the new operators. There are advantages in using the RelBuilder but when plans mix operators from different conventions (e.g., Enumerable and Jdbc) the builder and subsequently the trimmer cannot be used; the old and the new (trimmed) operator must be in the same convention.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)