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