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

Re: [HACKERS] Bgwriter behavior

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Bgwriter behavior
Date: 2004-12-31 00:04:48
Message-ID: 1104451488.3978.249.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Mon, 2004-12-27 at 22:21, Bruce Momjian wrote:
> Should we consider at least adjusting the meaning of bgwriter_percent?

Yes. As things stand, this is the only change that seems safe.

Here's a very short patch that implements this change within BufferSync
in bufmgr.c 

- No algorithm changes
- No error message changes
- Only change is the call to StrategyDirtyBufferList is made using the
maximum number of buffers that will be cleaned, rather than uselessly
trawling through all of shared_buffers

This changes the meaning of bgwriter_percent from "percent of dirty
buffers" to "percent of shared_buffers". The default settings of 1% of
1000 buffers gives up to 10 dirty block writes every 250ms

Benefit: allows performance tuning by increases options for setting
bgwriter_delay which would otherwise have an ineffectually high minimum
setting

Risk: low

1-line doc patch to follow, if this is approved.

-- 
Best Regards, Simon Riggs

Attachment: bg_v8.patch
Description: text/x-patch (2.7 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2004-12-31 01:14:39
Subject: Re: [HACKERS] Bgwriter behavior
Previous:From: Manfred KoizarDate: 2004-12-30 23:17:09
Subject: Re: Shared row locking

pgsql-patches by date

Next:From: Bruce MomjianDate: 2004-12-31 01:14:39
Subject: Re: [HACKERS] Bgwriter behavior
Previous:From: Tom LaneDate: 2004-12-30 21:49:24
Subject: Re: Win32 version numbers not correct (again, but this one is easy)

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