Re: [HACKERS] Re: 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