[
https://issues.apache.org/jira/browse/CALCITE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18043678#comment-18043678
]
TJ Banghart commented on CALCITE-7254:
--------------------------------------
Closed via
[3269244|https://github.com/apache/calcite/commit/32692447e8b3901e0ee9789a089b0f82566a186a]
Thank you for the review [~jensen]!
> Add a rule for sharing trivially equivalent RelNodes within Combine
> -------------------------------------------------------------------
>
> Key: CALCITE-7254
> URL: https://issues.apache.org/jira/browse/CALCITE-7254
> Project: Calcite
> Issue Type: Sub-task
> Reporter: TJ Banghart
> Assignee: TJ Banghart
> Priority: Major
> Labels: pull-request-available
>
> Introduce an optimization rule to identify and consolidate trivially
> equivalent {{RelNodes}} that appear within a {{Combine}} operator. Trivial
> equivalence is defined as two {{RelNodes}} having identical digests. When
> such equivalence is detected, the common subexpression should be lifted into
> a shared {{Spool}} reference, and each original occurrence should be replaced
> with a dependent on that {{{}Spool{}}}.
> An implementation may be able to build on the existing
> {{{}RelCommonExpressionSuggester{}}}, which currently identifies common
> expressions within individual queries. It may need to be extended to consider
> multiple queries or multiple branches within a single {{{}Combine{}}}.
> An important consideration will be how {{Combine}} handles cost estimation in
> the absence of optimization and how shared expressions might influence that
> model. We will likely need to evaluate how these lifted expressions interact
> with the cost model to ensure we aren’t over-rewarding shared subtrees or
> unintentionally skewing plan selection.
> We'd have to take care when managing interactions with other optimization
> rules. Filter pushdown, projection trimming, join reordering, etc... can
> alter digests and preclude trivial equivalence. The new rule will need
> safeguards to prevent conflicts or premature firing relative to these other
> optimizations.
> Some of the implementation details are likely to evolve as this develops.
> Initial focus would be on correctness and identifying the right insertion
> points in the optimization pipeline.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
