[
https://issues.apache.org/jira/browse/DERBY-3981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-3981:
--------------------------------------
Attachment: d3981.diff
Here's a patch which makes SQLBinary.hashCode() and SQLChar.hashCode()
calculate the hash codes in a way more similar to java.lang.String.hashCode().
In fact, SQLChar.hashCode() should now return the same hash code as
getString().substring(0,lastNonPadChar+1).hashCode().
With these changes, the average time reported by SelectDistinctTest on my
laptop went down from 6.6 seconds to 0.95 seconds on the CHAR(5) test, and from
2.7 seconds to 0.75 seconds on the CHAR(5) FOR BIT DATA test.
I haven't run the regression tests on the patch yet.
> Improve distribution of hash codes in SQLBinary and SQLChar
> -----------------------------------------------------------
>
> Key: DERBY-3981
> URL: https://issues.apache.org/jira/browse/DERBY-3981
> Project: Derby
> Issue Type: Improvement
> Components: Newcomer, Performance, SQL
> Affects Versions: 10.4.2.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: d3981.diff, distinct-test.diff
>
>
> SQLBinary.hashCode() and SQLChar.hashCode() use a very simple algorithm that
> just takes the sum of the values in the array. This gives a poor distribution
> of hash values because similar values will have a higher probability of
> mapping to the same hash code, and the higher bits won't be used unless the
> array is very long. We should change these methods so that they use an
> algorithm similar to the one used in java.lang.String.hashCode(), described
> here:
> <URL:http://java.sun.com/javase/6/docs/api/java/lang/String.html#hashCode()>.
> This may have a positive effect on the performance of hash scans as it will
> reduce the likelihood of collisions in the hash table.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
