Thread

RE: [HACKERS] Re: v7.1b4 bad performance

Schmidt, Peter <peter.schmidt@prismedia.com> — 2001-02-20T23:34:39Z

Hiroshi,
Is there any chance you can send the pgbench changes to me so that I can
test this scenario?
Thanks.
Peter

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: Tuesday, February 20, 2001 3:31 PM
> To: Tom Lane
> Cc: Schmidt, Peter; pgsql-hackers@postgresql.org; 
> pgsql-admin@postgresql.org
> Subject: Re: [HACKERS] Re: [ADMIN] v7.1b4 bad performance
> 
> 
> Tom Lane wrote:
> > 
> > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > >> Hmm, you mean you set up a separate test database for 
> each pgbench
> > >> "client", but all under the same postmaster?
> > 
> > > Yes. Different database is to make the conflict as less 
> as possible.
> > > The conflict among backends is a greatest enemy of CommitDelay.
> > 
> > Okay, so this errs in the opposite direction from the 
> original form of
> > the benchmark: there will be *no* cross-backend locking 
> delays, except
> > for accesses to the common WAL log.  That's good as a 
> comparison point,
> > but we shouldn't trust it absolutely either.
> > 
> 
> Of cource it's only one of the test cases.
> Because I've ever seen one-sided test cases, I had to
> provide this test case unwillingly.
> There are some obvious cases that CommitDelay is harmful
> and I've seen no test case other than such cases i.e
> 1) There's only one session.
> 2) The backends always conflict(e.g pgbench with scaling factor 1).
> 
> > >> What platform is this on --- in particular, how long a delay
> > >> is CommitDelay=1 in reality?  What -B did you use?
> > 
> > > 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.
> > 
> 
> OK I would try it later though I'm not sure I could
> increase -B that large in my current environment.
> 
> Regards,
> Hiroshi Inoue
>