[jira] [Updated] (CALCITE-3786) Add Digest (HashStrategy?) interface to enable efficient hashCode/equals for RexNode, RelNode

["Vladimir Sitnikov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Sitnikov updated CALCITE-3786:
---------------------------------------
    Description: 
Current digests for RexNode, RelNode, RelType, and similar cases use String concatenation.

It is easy to implement, however, it has drawbacks:
1) String objects cannot be reused. For instance, RexCall has operands, however, the digest is duplicated. It causes extra memory use and extra CPU for string copying
2) There's no way to have multiple #toString() methods. RelType might need multiple digests: "including field names", "excluding field names".


A suggested resolution might be behind the lines of

{code:java}
class Digest { // immutable
  final int hashCode; // speedup hashCode and equals
  final Object[] contents; // The values are either other Digest objects or Strings
  String toString(); // e.g. for debugging purposes
  int compareTo(Digest); // e.g. for debugging purposes.
}
{code}

Then the digest for RexCall could be the bits relevant to RexCall itself + digests of the operands (which can be reused as is)

  was:
Current digests for RexNode, RelNode, RelType, and similar cases use String concatenation.

It is easy to implement, however, it has drawbacks:
1) String objects cannot be reused. For instance, RexCall has operands, however, the digest is duplicated. It causes extra memory use, and extra CPU for string copying
2) There's no way to have multiple #toString() methods. RelType might need multiple digests: "including field names", "excluding field names".


Suggested resolution might be behind the lines of

{code:java}
class Digest { // immutable
  final int hashCode; // speedup hashCode and equals
  final Object[] contents; // The values are either other Digest objects or Strings
}
{code}

Then the digest for RexCall could be the bits relevant to RexCall itself + digests of the operands (which can be reused as is)


> Add Digest (HashStrategy?) interface to enable efficient hashCode/equals for RexNode, RelNode
> ---------------------------------------------------------------------------------------------
>
>                 Key: CALCITE-3786
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3786
>             Project: Calcite
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 1.21.0
>            Reporter: Vladimir Sitnikov
>            Priority: Major
>
> Current digests for RexNode, RelNode, RelType, and similar cases use String concatenation.
> It is easy to implement, however, it has drawbacks:
> 1) String objects cannot be reused. For instance, RexCall has operands, however, the digest is duplicated. It causes extra memory use and extra CPU for string copying
> 2) There's no way to have multiple #toString() methods. RelType might need multiple digests: "including field names", "excluding field names".
> A suggested resolution might be behind the lines of
> {code:java}
> class Digest { // immutable
>   final int hashCode; // speedup hashCode and equals
>   final Object[] contents; // The values are either other Digest objects or Strings
>   String toString(); // e.g. for debugging purposes
>   int compareTo(Digest); // e.g. for debugging purposes.
> }
> {code}
> Then the digest for RexCall could be the bits relevant to RexCall itself + digests of the operands (which can be reused as is)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)