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

Re: [HACKERS] Bgwriter behavior

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>,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: 2005-01-02 06:02:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > 	o  everyone agrees the current meaning of bgwriter_percent is
> > 	   useless (percent of dirty buffers)
> Oh?
> It's not useless by any means; it's a perfectly reasonable and useful
> definition that happens to be expensive to implement.  One of the
> questions that is not answered to my satisfaction is what is an adequate
> substitute that doesn't lose needed functionality.

I remembered this statement:

> I think there's a reasonable case to be made for redefining
> bgwriter_percent as the max percent of the total buffer list to scan
> (not the max percent of the list to return --- Jan correctly pointed out
> that the latter is useless).  Then we could modify
> StrategyDirtyBufferList so that the percent and maxpages parameters are
> passed in, so it can stop as soon as either one is satisfied.  This
> would be a fairly small/safe code change and I wouldn't have a problem
> doing it even at this late stage of the cycle.

Referenced here:

But I now see that Jan was objecting to the idea of the previouis patch
where bgwriter_percent is a percent of all buffers to return, which we
just discussed as redundant.

> > 	o  bgwriter_percent and bgwriter_maxpages are duplicate for a
> > 	   given number of buffers and it isn't clear which one takes
> > 	   precedence.
> Not unless the current definition of bgwriter_percent is changed.
> Please try to make sure that your summaries reduce confusion instead
> of increasing it.

OK, whatever.  My point is that many have critisized the current
behavior of bgwriter_percent and I haven't heard anyone defend it,
including Jan.

What bothers me is that we have known bgwriter needs tuning for months
and I am not sure we are any closer to improving it.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-hackers by date

Next:From: Robert TreatDate: 2005-01-02 07:55:42
Subject: Re: TODO item: make world safe for spaces in build/install
Previous:From: KorryDate: 2005-01-02 00:30:08
Subject: Re: exception handling in plpgsql

pgsql-patches by date

Next:From: Greg Sabino MullaneDate: 2005-01-02 14:18:21
Subject: Re: Allow pooled connections to list all prepared queries
Previous:From: lsunleyDate: 2005-01-01 23:50:21
Subject: psql session log

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