Re: [HACKERS] Bgwriter behavior - Mailing list pgsql-patches

Simon Riggs wrote:
> On Sat, 2005-01-01 at 06:20, Bruce Momjian wrote:
> > This change isn't going to make it for RC3, and it probably not
> > something we want to rush.
>
> OK. Thank you.
>
> > I think there are a few issues involved:
> >
> >     o  everyone agrees the current meaning of bgwriter_percent is
> >        useless (percent of dirty buffers)
> >     o  removal of bgwriter_percent will cause problems because
> >        postgresql.conf is only installed via initdb, so beta users
> >        will have to have some workaround so their existing
> >        postgresql.conf files work.
> >     o  bgwriter_percent and bgwriter_maxpages are duplicate for a
> >        given number of buffers and it isn't clear which one takes
> >        precedence.
> >     o  8.1 might use these variables with different meanings,
> >        causing slight upgrade confusion.
> >     o  Another idea is for bgwriter_percent to control how much of
> >        the buffer is scanned.
> >
>
> Agreed.
>
> Would add as item #1: current behaviour of bgwriter causes sub-optimal
> performance for 8.0, for systems with a high write workload, more CPUs
> and higher shared_buffers.
>
> > Tom feels bgwriter_maxpages is good because it allows the user to
> > specify the I/O traffic, while bgwriter_percent as total pages (not just
> > dirty ones) is perhaps easier to set a default (I/O load varies based on
> > buffer cache size) and perhaps easier to understand.
> >
>
> Agreed.
>
> > I am not sure what to suggest at this point but whatever solution we use
> > should take the above issues into account.
>
> Well, I think we're saying: its not in 8.0 now, and we take our time to
> consider patches for 8.1 and accept the situation that the parameter
> names/meaning will change in next release.

I have no problem doing something for 8.0 if we can find something that
meets all the items I mentioned.

One idea would be to just remove bgwriter_percent.  Beta/RC users would
still have it in their postgresql.conf, but it is commented out so it
should be OK.  If they uncomment it their server would not start but we
could just tell testers to remove it.  I see that as better than having
conflicting parameters.

Another idea is to have bgwriter_percent be the percent of the buffer it
will scan.  We could default that to 50% or 100%, but we then need to
make sure all beta/RC users update their postgresql.conf with the new
default because the commented-out default will not be correct.

At this point I see these as our only two viable options, aside from
doing nothing.

I realize our current behavior requires a full scan of the buffer cache,
but how often is the bgwriter_maxpages limit met?  If it is not a full
scan is done anyway, right?  It seems the only way to really add
functionality is to change bgwriter_precent to control how much of the
buffer is scanned.

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