Re: new group commit behavior not helping? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: new group commit behavior not helping?
Date
Msg-id CAEYLb_XahYyP+enAyfvMy86zxLF6v0=wx0qt9_3b8Tfs9eK6DQ@mail.gmail.com
Whole thread Raw
In response to Re: new group commit behavior not helping?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: new group commit behavior not helping?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 1 April 2012 06:41, Robert Haas <robertmhaas@gmail.com> wrote:
> There seem to be too relevant differences between your test and mine:
> (1) your test is just a single insert per transaction, whereas mine is
> pgbench's usual update, select, update, update, insert and (2) it
> seems that, to really see the benefit of this patch, you need to pound
> the server with a very large number of clients.  On this test, 250
> clients was the sweet spot.

*refers to original early January benchmark*

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.

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

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Switching to Homebrew as recommended Mac install?
Next
From: Jay Levitt
Date:
Subject: Re: Switching to Homebrew as recommended Mac install?