Improve the performance of IN checking #7410
Conversation
This commit changes the output order of operations using hash codes, such as hash joins, DISTINCT, and grouping for aggregation.
|
@spacecowboy How do I mark this PR so that it does not show up in the 3.1 changelog? It's a back-port of something that is already in 3.1 (and already in the changelog) |
| } | ||
|
|
||
| (eagerizedValue, eagerOther) match { | ||
| case (null, null) => true |
There was a problem hiding this comment.
It says above that this class does not handle null values...? Which variables is that comment directed at?
|
@systay you have already done so by adding |
|
|
||
| private def hashCode(o: Any): Int = o match { | ||
| case null => 0 | ||
| case n: Number => n.longValue().hashCode() |
There was a problem hiding this comment.
The Long zero has the hash code zero, so all numbers that go to a zero long will have the same hash code as null here. Given that zero might be the most commonly used number, wouldn't it make sense to give null another hash code, like -1, or Int.MAX_VALUE?
This commit changes the output order of operations using hash codes,
such as hash joins, DISTINCT, and grouping for aggregation.
This is already in 3.1, so a null-merge should be done when forward merging.
changelog: [3.0, cypher] Improve the performance of IN checking.