Re: Proposal: String key space for advisory locks

On Mon, Oct 26, 2009 at 06:35:13PM -0700, Christophe Pettus wrote:
>
> On Oct 26, 2009, at 5:24 PM, Itagaki Takahiro wrote:
>
>> Hmmm, hashtext() returns int32. ,
>> Can you reduce the collision issue if we had hashtext64()?
>
> That would certainly reduce the chance of a collison considerably, assuming 
> the right algorithm.
>
> --
> -- Christophe Pettus
>    xof@thebuild.com
>
The current hash function can already support generating a 64-bit
hash value by using both the b and c values. The function is called
hashlittle2 and has this comment in the original Bob Jenkins 2006
code:

/** hashlittle2: return 2 32-bit hash values** This is identical to hashlittle(), except it returns two 32-bit hash*
valuesinstead of just one.  This is good enough for hash table* lookup with 2^^64 buckets, or if you want a second hash
ifyou're not* happy with the first, or if you want a probably-unique 64-bit ID for* the key.  *pc is better mixed than
*pb,so use *pc first.  If you want* a 64-bit value do something like "*pc + (((uint64_t)*pb)<<32)".*/
 

This should be a simple change. It would be worth running it by
the developer community to figure out how to add this functionality
in a way that will make 64-bit hashes available easily to other
code in the DB, perhaps even using them in very large hash indexes.

Regards,
Ken