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

Knut Anders Hatlen updated DERBY-3981:
--------------------------------------

    Attachment: distinct-test.diff

Attaching a new JUnit performance test which tests SELECT DISTINCT performance. 
There is one test case which performs SELECT DISTINCT on a table with a 
non-indexed CHAR(5) column which contains all permutations of 'ABCDE'. This is 
the worst case for the current hash function, as all the values will end up in 
the same bucket. The other test case performs the same test on a table with a 
CHAR(5) FOR BIT DATA column with the same distribution.

> 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
>            Priority: Minor
>         Attachments: 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.

Reply via email to