From: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Initial 9.2 pgbench write results |
Date: | 2012-02-27 20:35:37 |
Message-ID: | 4F4BE919.8040202@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/27/2012 08:08 AM, Robert Haas wrote:
> OK, fair point. But I don't think any of us - Greg included - have an
> enormously clear idea why turning the background writer off is
> improving performance in some cases. I think we need to understand
> that better before we start changing things.
Check out
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00895.php for
proof this is not a new observation.
The fact that there are many workloads where the background writer just
gets in the way was clear since the 8.3 development four years ago. One
of my guiding principles then was to err on the side of doing less in
the default configuration. The defaults in 8.3 usually do less than the
8.2 configuration, given a reasonable shared_buffers size.
Since then we've found a few cases where it measurably helps. The
examples on my recent graphs have a few such tests. Simon has mentioned
seeing big gains during recovery from having 2 processes pushing I/O out.
One of the reasons I drilled right into this spot is because of fears
that running the writer more often would sprout regressions in TPS. I
can't explain exactly why exactly having backends write their own
buffers out at the latest possible moment works significantly better in
some cases here. But that fact isn't new to 9.2; it's just has a
slightly higher potential to get in the way, now that the writing
happens during the sync phase.
--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-02-27 20:39:51 | Re: pgstat documentation tables |
Previous Message | Tom Lane | 2012-02-27 20:25:46 | Re: pgstat documentation tables |