| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Horribly slow hash join |
| Date: | 2004-04-18 06:43:09 |
| Message-ID: | 873c719476.fsf@stark.xeocode.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> >> (Also, I have been harboring some notions of supporting cross-type hash
> >> joins for integer types, which will not work unless small int8 values hash
> >> the same as int4 etc.)
>
> > The obvious way to modify the hash function is to xor the high 32 bits with
> > the low 32 bits. That maintains the property you need
>
> No it doesn't ...
Eh? Oh, negative numbers? So low^high^sign.
I wonder if it makes sense to have check the hash distribution after
generating the table and if it's bad then throw it away and try again with a
different hash function. The "different hash function" would probably just be
a seed value changing. Probably way overkill though.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-04-18 15:39:10 | Re: Horribly slow hash join |
| Previous Message | Dennis Bjorklund | 2004-04-18 06:18:47 | Re: Horribly slow hash join |