[
https://issues.apache.org/jira/browse/CALCITE-7111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18010503#comment-18010503
]
Mihai Budiu commented on CALCITE-7111:
--------------------------------------
Finding common sub-expressions should probably have two implementations: one at
the Rex and one at the Rel level.
However, once you find common subexpressions at the Rex level there is no easy
way to take advantage of that.
But maybe that is in the scope of a different issue.
(In our compiler we added a "let" expression which allows you to evaluate
common subexpressions only once: "let x = expression in expression".)
I saw this proposal somewhere in Calcite at some point.
> Add an API for finding common relational sub-expressions
> --------------------------------------------------------
>
> Key: CALCITE-7111
> URL: https://issues.apache.org/jira/browse/CALCITE-7111
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Stamatis Zampetakis
> Assignee: Stamatis Zampetakis
> Priority: Major
>
> There have been various tickets (CALCITE-5631) and
> [discussions|https://lists.apache.org/thread/oj7kzz39n4jn0jj7vgflzwl5xr65s3h5]
> touching the problem of optimizing queries with common sub-expressions. A
> recurrent need is given a query/plan/RelNode to identify common
> sub-expressions and for that purpose multiple algorithms can be developed
> with different trade-offs. Someone may opt to implement a complex algorithm
> from a research paper based on integer linear programming (ILP) while another
> one may simply go for a structure based traversal.
> The goal of this ticket is to introduce a simple interface that given a
> RelNode finds/detects/suggests common sub-expressions.
> {code:java}
>
> @API(since = "1.41.0", status = API.Status.EXPERIMENTAL)
> public interface RelCommonExpressionSuggester {
> Collection<RelNode> suggest(RelNode input, Context context);
> }
> {code}
> The interface and its Javadoc will go along with a simple implementation
> detecting exact matches and some tests.
> The main motivation behind this proposal comes from Apache Hive and Apache
> Impala that aim to exploit common sub-expressions during planning. Instead of
> crafting separate interfaces for each project or copy-pasting code around it
> is natural to have the basic interfaces in calcite-core. Moreover, this
> proposal allows closed source implementations of the interface to be used in
> each project without ending up with contrived cyclic dependencies.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
