On 1/29/08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Vlad <marchenko@gmail.com> writes:
> > 2. We ran several tests and found 8.3 generally 10% slower than 8.2.6.
>
> The particular case you are showing here seems to be all about the speed
> of hash aggregation --- at least the time differential is mostly in the
> HashAggregate step. What is the data type of a_id? I speculate that
> you're noticing the slightly slower/more complicated hash function that
> 8.3 uses for integers. On a case where the data was well distributed
> you'd not see any countervailing efficiency gain from those extra
> cycles.
AFAIK we have a plan to update string hash in 8.4 to fastest
available (Jenkins lookup3). Maybe we should update integer
hash too then to the best:
http://www.cris.com/~Ttwang/tech/inthash.htm
("32 bit Mix Functions" is the one).
--
marko