Re: [HACKERS] Bgwriter behavior - Mailing list pgsql-patches
From | Bruce Momjian |
---|---|
Subject | Re: [HACKERS] Bgwriter behavior |
Date | |
Msg-id | 200501032009.j03K9rs16407@candle.pha.pa.us Whole thread Raw |
In response to | Re: [HACKERS] Bgwriter behavior (Simon Riggs <simon@2ndquadrant.com>) |
Responses |
Re: [HACKERS] Bgwriter behavior
Re: [HACKERS] Bgwriter behavior Re: [HACKERS] Bgwriter behavior |
List | pgsql-patches |
OK, we have a submitted patch that attempts to improve bgwriter by making bgwriter_percent control what percentage of the buffer is scanned. The patch still needs doc changes and a change to the default value but at this point we need a vote on the patch. Is it: * too late for 8.0 * not the right improvement * to be applied with doc/default additions Comments? --------------------------------------------------------------------------- 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@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
pgsql-patches by date: