Skip site navigation (1) Skip section navigation (2)

Re: Final background writer cleanup for 8.3

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Final background writer cleanup for 8.3
Date: 2007-08-31 12:46:28
Message-ID: 46D80DA4.8010107@Yahoo.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 8/24/2007 8:41 AM, Heikki Linnakangas wrote:
> If anyone out there has a repeatable test case where bgwriter does help,
> I'm all ears. The theory of moving the writes out of the critical path
> does sound reasonable, so I'm sure there is test case to demonstrate the
> effect, but it seems to be pretty darn hard to find.

One could try to dust off this TPC-W benchmark.

     http://pgfoundry.org/projects/tpc-w-php/

Again, the original theory for the bgwriter wasn't moving writes out of 
the critical path, but smoothing responsetimes that tended to go 
completely down the toilet during checkpointing, causing all the users 
to wake up and overload the system entirely.

It is well known that any kind of bgwriter configuration other than OFF 
does increase the total IO cost. But you will find that everyone who has 
SLA's that define maximum response times will happily increase the IO 
bandwidth to give an aggressively configured bgwriter room to work.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2007-08-31 12:49:05
Subject: Re: enum types and binary queries
Previous:From: Suresh_Date: 2007-08-31 12:37:37
Subject: Re: Performing antijoin in postgres

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group