RE: Re: [ADMIN] v7.1b4 bad performance - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: Re: [ADMIN] v7.1b4 bad performance
Date
Msg-id EKEJJICOHDIEMGPNIFIJAEMCDKAA.Inoue@tpf.co.jp
Whole thread Raw
In response to Re: Re: [ADMIN] v7.1b4 bad performance  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Responses RE: Re: [ADMIN] v7.1b4 bad performance  (Lincoln Yeoh <lyeoh@pop.jaring.my>)
List pgsql-hackers
> Tom Lane wrote:
> > 
> > > platform) i686-pc-linux-gnu, compiled by GCC 
> egcs-2.91.60(turbolinux 4.2)
> > > min delay) 10msec according to your test program.
> > > -B)  64 (all other settings are default)
> > 
> > Thanks.  Could I trouble you to run it again with a larger -B, say
> > 1024 or 2048?  What I've found is that at -B 64, the benchmark is
> > so constrained by limited buffer space that it doesn't reflect
> > performance at a more realistic production setting.
> > 
> 
> Hmm the result doesn't seem that obvious.
>

I tried with -B 1024 10 times for commit_delay=0 and 1 respectively.
The average result of 'pgbench -c 10 -t 100' is as follows.

[commit_delay=0]26.462817(including connections establishing)26.788047(excluding connections establishing)
[commit_delay=1]27.630405(including connections establishing)28.042666(excluding connections establishing)

Hiroshi Inoue


pgsql-hackers by date:

Previous
From: Chris Storah
Date:
Subject: low priority postmaster threads?
Next
From: Karel Zak
Date:
Subject: Re: Encoding names