On 1/29/08, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Vlad <marchenko@xxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
