From: | Greg Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Saner interval hash function |
Date: | 2009-04-04 14:12:53 |
Message-ID: | 4136ffa0904040712s57d4c8b3u93151438ed1f4985@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 3, 2009 at 10:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The present implementation of interval_hash() is very carefully designed
> and coded ... to meet the wrong specification :-(. What it should
> be doing is producing equal hashcodes for values that interval_eq()
> considers equal. The error is exhibited in the recent bug report #4748.
It would be nice if we had a way to generate a lot of similar values
for a every data type. Then we could have a regression test which
checks for each data type that the hash function matches the equality
operator -- and for that matter that the various inequality operators
are also consistent.
I'm not sure how to generate values though. For a lot of data types it
would be hard to generate values densely enough to trigger any bugs.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-04-04 14:40:42 | Re: Documentation Update: Document pg_start_backup checkpoint behavior |
Previous Message | Dimitri Fontaine | 2009-04-04 11:26:00 | Re: a few crazy ideas about hash joins |