On Sat, Mar 31, 2012 at 8:31 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> Why the low value for wal_writer_delay?
A while back I was getting a benefit from cranking that down. I could
try leaving it out and see if it matters.
>> master:
>> 01 tps = 118.968446 (including connections establishing)
>> 02 tps = 120.666865 (including connections establishing)
>> 04 tps = 209.624437 (including connections establishing)
>> 08 tps = 377.387029 (including connections establishing)
>> 16 tps = 695.172899 (including connections establishing)
>> 32 tps = 1318.468375 (including connections establishing)
>>
>> REL9_1_STABLE:
>> 01 tps = 117.037056 (including connections establishing)
>> 02 tps = 119.393871 (including connections establishing)
>> 04 tps = 205.958750 (including connections establishing)
>> 08 tps = 365.464735 (including connections establishing)
>> 16 tps = 673.379394 (including connections establishing)
>> 32 tps = 1101.324865 (including connections establishing)
>
> (presumably s/tps/clients/ was intended here)
The number at the beginning of each line is the number of clients.
Everything after the first space is the output of pgbench for the
median of three runs with that number of clients.
>> Is this expected behavior? Is this not the case where it's supposed
>> to help? I thought Peter G. posted results showing a huge improvement
>> on this kind of workload, and I thought Heikki reproduced them on a
>> different server, so I'm confused why I can't.
>
> The exact benchmark that I ran was the update.sql pgbench-tools
> benchmark, on my laptop. The idea was to produce a sympathetic
> benchmark with a workload that was maximally commit-bound. Heikki
> reproduced similar numbers on his laptop, iirc. Presumably the default
> TPC-B-like transaction test has been used here.
Yes.
> You didn't mention what kind of disks this server has - I'm not sure
> if that information is available elsewhere. That could be highly
> pertinent.
I'm a little fuzzy on that, but I think it's a collection of 600GB 10K
RPM SAS SFF disk drives with LVM sitting on top.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
