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(at)tpf(dot)co(dot)jp]
> Sent: Tuesday, February 20, 2001 3:31 PM
> To: Tom Lane
> Cc: Schmidt, Peter; pgsql-hackers(at)postgresql(dot)org;
> pgsql-admin(at)postgresql(dot)org
> Subject: Re: [HACKERS] Re: [ADMIN] v7.1b4 bad performance
>
>
> Tom Lane wrote:
> >
> > "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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
>