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

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

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