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)
