Re: new group commit behavior not helping?

On Mon, Apr 2, 2012 at 8:14 AM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> While the graph that I produced was about the same shape as yours, the
> underlying hardware was quite different, and indeed with my benchmark
> group commit's benefits are more apparent earlier - at 32 clients,
> throughput has more-than doubled compared to pre group commit
> Postgres, which has already just about plateaued. I did include hdparm
> information for the disk that my benchmark was performed on at the
> time. While write-caching was not disabled, I would expect that the
> commit speed of my laptop - which has a fairly unremarkable 7200RPM
> disk - is slower than the 10K RPM SAS disks that you used. A formal
> benchmark of respective raw commit speeds may shed more light on this.

We could compare pg_test_fsync results if you are interested.

> Why did I even bother with such a sympathetic benchmark, when a
> benchmark on a large server could have been performed instead? Well,
> the reality is that many of our users have a commit speed that is
> comparable to my laptop. In particular, the increasing prevalence of
> "cloud" type deployments, make group commit a timely feature. If you
> wanted to demonstrate the wonders of group commit, I'd take that
> particular tone. I'm sure that if you re-ran this benchmark with a
> battery-backed cache, you would observe a much smaller though still
> very apparent benefit, but if you wanted to make the feature sound
> appealing to traditional enterprise users that are using a BBU, a good
> line would be "this is what will save your bacon that day that your
> procedures fail and your BBU battery dies".

Well, on my pgbench tests, synchronous_commit=on is still far, far
slower than synchronous_commit=off, even on 9.2; see the OP. It's
certainly an improvement, of course: the 15-20% improvement at 32
clients is nothing to sneeze at, and it's hard to see how we can
really hope to do much better. But it certainly makes me understand
why people pay for BBUs.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company