[
https://issues.apache.org/jira/browse/CALCITE-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18115699#comment-18115699
]
Michael Braun commented on CALCITE-7783:
----------------------------------------
[~julianhyde] I've tightened the benchmark. It does include some planning
overhead but it's much clearer now. I do plan on more PRs to address other
aspects aside from the SetOps here
> Speed up deepEquals and deepHashCode for LogicalUnion, LogicalIntersect and
> LogicalMinus
> ----------------------------------------------------------------------------------------
>
> Key: CALCITE-7783
> URL: https://issues.apache.org/jira/browse/CALCITE-7783
> Project: Calcite
> Issue Type: Improvement
> Reporter: Michael Braun
> Priority: Minor
> Labels: pull-request-available
>
> AbstractRelNode's default deepEquals()/deepHashCode() builds a
> RelDigestWriter and a PairList and re-runs explainTerms() on both sides for
> every comparison.
> LogicalJoin, LogicalFilter and LogicalProject already avoid this: their
> abstract core classes expose protected deepEquals0()/deepHashCode0() helpers
> that compare fields directly, and the final Logical* subclasses override
> deepEquals()/deepHashCode() to call them, per AbstractRelNode's own javadoc
> recommendation. LogicalUnion, LogicalIntersect and LogicalMinus never
> received the same treatment, despite being equally eligible: all three are
> final, and SetOp's explainTerms() output (inputs, "all") is already their
> complete identity.
> Proposed fix: add deepEquals0()/deepHashCode0() helpers to SetOp, mirroring
> Join's, and override deepEquals()/deepHashCode() on LogicalUnion,
> LogicalIntersect and LogicalMinus only -- other subclasses (EnumerableUnion,
> JdbcUnion, BindableUnion, etc.) are non-final and keep the safe digest-based
> default.
> A new JMH benchmark should be added to HepPlanner's digest dedup for
> UNION/INTERSECT/MINUS trees.
> This showed up in profiling the planning on our application which has quick
> execution but a heavy planning stage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
