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: 200501020602.j02629n22398@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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:

http://archives.postgresql.org/pgsql-hackers/2004-12/msg00703.php

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 | http://candle.pha.pa.us
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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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