Re: [HACKERS] Bgwriter behavior

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
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: 2005-01-04 05:13:52
Message-ID: 200501040513.j045Dqx07167@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


This has been saved for the 8.1 release:

http:/momjian.postgresql.org/cgi-bin/pgpatches2

---------------------------------------------------------------------------

Simon Riggs wrote:
> On Sat, 2005-01-01 at 17:47, Simon Riggs wrote:
> > On Sat, 2005-01-01 at 17:01, Bruce Momjian wrote:
> > > Simon Riggs wrote:
> > >
> > > > 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.
> >
> > Can't say I like that at first thought. I'll think some more though...
> >
> > > Another idea is to have bgwriter_percent be the percent of the buffer it
> > > will scan.
> >
> > Hmmm....well that was my original suggestion (bg2.patch on 12 Dec)
> > (...though with a bug, as Neil pointed out)
> >
> > > 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.
> >
> > ...we just differ/ed on what the default should be...
> >
> > > 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?
> >
> > Well, if you heavy a very heavy read workload then that would be a
> > problem. I was more worried about concurrency in a heavy write
> > situation, but I can see your point, and agree.
> >
> > (Idea #1 still suffers from this, so we should rule it out...)
> >
> > > It seems the only way to really add
> > > functionality is to change bgwriter_precent to control how much of the
> > > buffer is scanned.
> >
> > OK. I think you've persuaded me on idea #2, if I understand you right:
> >
> > bgwriter_percent = 50 (default)
> > bgwriter_maxpages = 100 (default)
> >
> > percent is the number of shared_buffers we scan, limited by maxpages.
> >
> > (I'll code it up in a couple of hours when the kids are in bed)
>
> Here's the basic patch - no changes to current default values or docs.
>
> Not sure if this is still interesting or not...
>
> --
> Best Regards, Simon Riggs

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend

--
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 Greg Stark 2005-01-04 06:46:53 Re: uptime() for postmaster
Previous Message Bruce Momjian 2005-01-04 05:13:24 Re: TODO item: make world safe for spaces in build/install

Browse pgsql-patches by date

  From Date Subject
Next Message Karel Zak 2005-01-04 08:08:40 Re: Implementing RESET CONNECTION ...
Previous Message Bruce Momjian 2005-01-04 04:16:07 Re: Grammer Cleanup