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-05-04 03:57:24 |
Message-ID: | 10004.1178251044@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Neil Conway <neilc(at)samurai(dot)com> writes:
> On Mon, 2007-30-04 at 00:04 -0400, Tom Lane wrote:
>> 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.
> What about teaching hash_numeric() to explicitly ignore leading and
> trailing zero digits?
Hm, but apply hash_any() to the remaining digits? That might work, if
you are careful about how you factor the weight into it (or just not try
to use the weight in the hash).
>> Perhaps a suitable test would be to compare the number of
>> hash collisions in a large set of randomly-chosen-but-distinct
>> numeric values.
> Okay, I did a little testing.
> [ test that totally destroys my proposed hash function ]
OK, so *that* idea doesn't work. How about yours above?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2007-05-04 06:55:19 | Re: Updated bitmap index patch |
Previous Message | Neil Conway | 2007-05-04 03:03:59 | Re: Hash function for numeric (WIP) |