Re: Initial 9.2 pgbench write results

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

In response to

Responses

Browse pgsql-hackers by date

  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