Re: 8.2 is 30% better in pgbench than 8.3 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 8.2 is 30% better in pgbench than 8.3
Date
Msg-id 347.1185039022@sss.pgh.pa.us
Whole thread Raw
In response to 8.2 is 30% better in pgbench than 8.3  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Responses Re: 8.2 is 30% better in pgbench than 8.3  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Re: 8.2 is 30% better in pgbench than 8.3  (Greg Smith <gsmith@gregsmith.com>)
Re: 8.2 is 30% better in pgbench than 8.3  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Re: 8.2 is 30% better in pgbench than 8.3  (Josh Berkus <josh@agliodbs.com>)
Re: 8.2 is 30% better in pgbench than 8.3  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> I was little bit surprised. Is any reason for it?

Are you sure you're comparing apples to apples?  In particular the
default autovacuuming setup is entirely different.  With autovac off
I see 8.3 as faster than 8.2 in pgbench.

Also, remember a couple rules of thumb for choosing pgbench parameters:
keep -c less than the -s scale factor you used for pgbench -i (otherwise
you're mostly measuring update contention, because there are only -s
different rows in the branches table); and use -t at least 1000 or so
(otherwise startup transients are significant).

Note to all: we ***HAVE TO*** settle on some reasonable default
vacuum_cost_delay settings before we can ship 8.3.  With no cost delay
and two or three workers active, 8.3's autovac does indeed send
performance into the tank.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: 8.2 is 30% better in pgbench than 8.3
Next
From: "Pavel Stehule"
Date:
Subject: Re: 8.2 is 30% better in pgbench than 8.3