"Vlad Marchenko" <[EMAIL PROTECTED]> writes:
> I'm curious if that new hash aggregation algorithm was put in 8.3 with the
> performance increase as a goal
Yes.
http://archives.postgresql.org/pgsql-hackers/2007-05/msg01179.php
http://archives.postgresql.org/pgsql-committers/2007-06/msg7.php
(a
More test results for public. We ran my original query and found out
that on 4 cores CPU:
1 thread test 8.2 bits 8.3 by 10..15%
4 threads 8.2. wins 8.3 by ~2%
8 threads 8.3 finally wins 8.2 by ~2%
the same data set was affected during multi-threaded runs, but it's
100% cached from the disk. I gue
I just tried adjusting two parameters:
enable_hashagg = off
both versions run slower, still 8.2 quicker than 8.3 (by ~ the same %)
enable_hashjoin = off
both versions run slower, still 8.2 quicker than 8.3 (by ~ the same %)
On Jan 29, 2008 10:34 AM, Clodoaldo <[EMAIL PROTECTED]> wrote:
> Vlad,
le_hashagg set to off?
Saudações, Clodoaldo Pinto Neto
> - Original Message -
> From: "Tom Lane" <[EMAIL PROTECTED]>
> To: "Vlad" <[EMAIL PROTECTED]>
> Cc: "PG-General"
> Sent: Monday, January 28, 2008 9:13 PM
> Subject: Re: [GENER
uot;
Sent: Monday, January 28, 2008 9:13 PM
Subject: Re: [GENERAL] 8.3RC2 vs 8.2.6 testing results
Vlad <[EMAIL PROTECTED]> 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 a
On 1/29/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> Vlad <[EMAIL PROTECTED]> 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 most
On Mon, 28 Jan 2008, Tom Lane wrote:
I speculate that you're noticing the slightly slower/more complicated
hash function that 8.3 uses for integers.
There was a similar slowdown in the Clodaldo case you tracked down
recently. Is it worth considering an addition to the release notes
warning
Vlad <[EMAIL PROTECTED]> 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
> This last bit often means there's some overhead in the systems
> timeofday() function calls.
>
> If you just use \timing from psql, and run the script without explain
> analyze, what speeds do you get on each?
>
17480ms (8.2.6)
20342ms (8.3RC2)
--
Vlad
---(end of broad
On Jan 28, 2008 3:56 PM, Vlad <[EMAIL PROTECTED]> wrote:
> Hello,
>
> 1. Freshly imported DB size on disk was about 3% smaller for 8.3
> 2. We ran several tests and found 8.3 generally 10% slower than 8.2.6.
> We took special measures to make sure that no third factors involved
> (no other apps run
Pavel:
thanks for your feedback. To me plans generated by 8.2 and 8.3 are
equal and only differ by execution times. (I don't know, maybe email
wrap'ed lines, so I've attached plans to my message). Also, I confirm
that that parameter was increased (to 100) before the ran tests.
On Jan 28, 2008 4:2
On 28/01/2008, Pavel Stehule <[EMAIL PROTECTED]> wrote:
> Hello
>
> 8.3 plan is not optimal.
>
> >-> Hash Join (cost=2379.09..108954.69 rows=550548 width=52)
> > (actual time=76.188..8177.510 rows=2593557 loops=1)
>
> please, try to increase statistics
I am blind, I am sorry, It's noise, you
Hello
8.3 plan is not optimal.
>-> Hash Join (cost=2379.09..108954.69 rows=550548 width=52)
> (actual time=76.188..8177.510 rows=2593557 loops=1)
please, try to increase statistics
default_statistics_target (in postgresql.conf) to 100 and repeat
import and your test.
Regards
Pavel Stehul
Hello,
I wanted to share performance-related test results for Postgresql
8.3RC2 and 8.2.6. In both cases we used a freshly imported database
followed by analyze verbose command. Same server was used for testing
(2.6.23.14-107.fc8 x86_64) for each versions; both postgreses were
compiled with "-O3 -
14 matches
Mail list logo
