[jira] [Commented] (CALCITE-7783) Speed up deepEquals and deepHashCode for LogicalUnion, LogicalIntersect and LogicalMinus

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

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

Julian Hyde commented on CALCITE-7783:
--------------------------------------

I'd like to see the numbers before we accept changes that are alleged to improve performance.

> 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
>
> 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)