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

Tom Lane wrote:
> 
> I wrote:
> > Thus, our past arguments about whether a few microseconds of delay
> > before commit are a good idea seem moot; we do not have any portable way
> > of implementing that, and a ten millisecond delay for commit is clearly
> > Not Good.
> 
> I've now finished running a spectrum of pgbench scenarios, and I find
> no case in which commit_delay = 0 is worse than commit_delay > 0.
> Now this is just one benchmark on just one platform, but it's pretty
> damning...
> 

In your test cases I always see "where bid = 1" at "update branches"
i.e.
  update branches set bbalance = bbalance + ... where bid = 1

ISTM there's no multiple COMMIT in your senario-s due to
their lock conflicts. 

Regards,
Hiroshi Inoue