Re: Horribly slow hash join - Mailing list pgsql-performance

From Dennis Bjorklund
Subject Re: Horribly slow hash join
Date
Msg-id Pine.LNX.4.44.0404190640010.4551-100000@zigo.dhs.org
Whole thread Raw
In response to Re: Horribly slow hash join  (Bruno Wolff III <bruno@wolff.to>)
Responses Re: Horribly slow hash join
List 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


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Wierd context-switching issue on Xeon
Next
From: Greg Stark
Date:
Subject: Re: Horribly slow hash join