Re: new group commit behavior not helping?

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: new group commit behavior not helping?
Date: 2012-04-02 12:14:31
Message-ID: CAEYLb_XahYyP+enAyfvMy86zxLF6v0=wx0qt9_3b8Tfs9eK6DQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1 April 2012 06:41, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jay Levitt 2012-04-02 12:17:07 Re: Switching to Homebrew as recommended Mac install?
Previous Message Andrew Dunstan 2012-04-02 11:25:37 Re: Switching to Homebrew as recommended Mac install?