Skip site navigation (1) Skip section navigation (2)

Re: Hash function for numeric (WIP)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Hash function for numeric (WIP)
Date: 2007-04-30 04:04:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
Neil Conway <neilc(at)samurai(dot)com> writes:
> On Fri, 2007-04-27 at 10:02 -0400, Tom Lane wrote:
>> Perhaps a sufficiently robust way would be to form the hash as the
>> XOR of each supplied digit, circular-shifted by say 3 times the
>> digit's weight. 

> The only objection I have to this is that it means we need to have
> another hash function in the backend. The Jenkins hash we use in
> hash_any() has been studied and we can have at least some confidence in
> its collision-resistance, etc.

I'm still not very comfortable with that.  You're proposing to add a
pretty obvious failure mechanism --- any numeric-returning function
that failed to "normalize" its output would now create a subtle,
hard-to-find bug.  Even if you can promise that all the functions in
numeric.c get it right, what of user-written add-ons?  And the only
return for taking this risk is speculation that the performance of the
hash function might be better.

I think if you want to go this way, you should at least provide some
evidence that we get a hashing performance benefit in exchange for
adding a new restriction on numeric-value validity.  Perhaps a suitable
test would be to compare the number of hash collisions in a large set of
randomly-chosen-but-distinct numeric values.

			regards, tom lane

In response to


pgsql-patches by date

Next:From: Zdenek KotalaDate: 2007-04-30 14:11:43
Subject: Re: Fix for large file support (nonsegment mode support)
Previous:From: Greg SmithDate: 2007-04-30 02:07:54
Subject: Re: too much WAL volume

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group