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

["Michael Braun (Jira)" <ji...@apache.org>]

Michael Braun created CALCITE-7783:
--------------------------------------

             Summary: 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


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)