From: | "Marko Kreen" <markokr(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Vlad <marchenko(at)gmail(dot)com>, PG-General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: 8.3RC2 vs 8.2.6 testing results |
Date: | 2008-01-29 07:45:04 |
Message-ID: | e51f66da0801282345s16d9d128n227dc33c41a3c0cf@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 1/29/08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Vlad <marchenko(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2008-01-29 08:06:45 | Re: [GENERAL] SHA1 on postgres 8.3 |
Previous Message | Greg Smith | 2008-01-29 05:24:29 | Re: 8.3RC2 vs 8.2.6 testing results |