| From: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
|---|---|
| To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Horribly slow hash join |
| Date: | 2004-04-19 04:43:16 |
| Message-ID: | Pine.LNX.4.44.0404190640010.4551-100000@zigo.dhs.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Sun, 18 Apr 2004, Bruno Wolff III wrote:
> Another option would be to put the numbers into two int4s. For int4 or
> smaller types one of these would be zero. int8s would be split between
> the two. The hash function would then be defined on the two int4s.
Sure, this is an internal calculation in the hash function. The only
important thing is that the number 7 (for example) gives the same hash
value no matter if it is an int2 or an int8 and that the hash function
works well also for int8 numbers (which is does not today).
At least that was the properties I understood that we wanted.
We got side tracked into talking about what datatype exists in all
platforms, that's not an issue at all.
--
/Dennis Björklund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2004-04-19 05:29:19 | Re: Horribly slow hash join |
| Previous Message | Tom Lane | 2004-04-19 03:19:56 | Re: Wierd context-switching issue on Xeon |