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

"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.

>> 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.

regards, tom lane