Re: Just-in-time Background Writer Patch+Test Results - Mailing list pgsql-hackers

From Decibel!
Subject Re: Just-in-time Background Writer Patch+Test Results
Date
Msg-id 20070906225040.GQ38801@decibel.org
Whole thread Raw
In response to Re: Just-in-time Background Writer Patch+Test Results  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Just-in-time Background Writer Patch+Test Results
List pgsql-hackers
On Thu, Sep 06, 2007 at 09:20:31AM -0500, Kevin Grittner wrote:
> >>> On Wed, Sep 5, 2007 at 10:31 PM, in message
> <Pine.GSO.4.64.0709052324020.25284@westnet.com>, Greg Smith
> <gsmith@gregsmith.com> wrote:
> >
> > -There are two magic constants in the code:
> >
> >      int         smoothing_samples = 16;
> >      float       scan_whole_pool_seconds = 120.0;
> >
>
> > I personally
> > don't feel like these constants need to be exposed for tuning purposes;
>
> > Determining
> > whether these should be exposed as GUC tunables is certainly an open
> > question though.
>
> If you exposed the scan_whole_pool_seconds as a tunable GUC, that would
> allay all of my concerns about this patch.  Basically, our problems were

I like the idea of not having that as a GUC, but I'm doubtful that it
can be hard-coded like that. What if checkpoint_timeout is set to 120?
Or 60? Or 2000?

I don't know that there should be a direct correlation, but ISTM that
scan_whole_pool_seconds should take checkpoint intervals into account
somehow.
--
Decibel!, aka Jim Nasby                        decibel@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

pgsql-hackers by date:

Previous
From: Mark Mielke
Date:
Subject: Re: Hash index todo list item
Next
From: Tom Lane
Date:
Subject: Re: [FEATURE REQUEST] Streaming Onlinebackup (Maybe OFFTOPIC)