Re: [Testperf-general] BufferSync and bgwriter - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [Testperf-general] BufferSync and bgwriter
Date
Msg-id 1103403159.2893.56.camel@localhost.localdomain
Whole thread Raw
In response to Re: [Testperf-general] BufferSync and bgwriter  (Richard Huxton <dev@archonet.com>)
List pgsql-hackers
On Thu, 2004-12-16 at 17:54, Richard Huxton wrote:
> Josh Berkus wrote:
> >>Clearly, OSDL-DBT2 is not a real world test! That is its benefit, since
> >>it is heavily instrumented and we are able to re-run it many times
> >>without different parameter settings. The application is well known and
> >>doesn't suffer that badly from factors that would allow certain effects
> >>to be swamped. If it had too much randomness or variation, it would be
> >>difficult to interpret.
> > 
> > I don't think you followed me.   The issue is that for parameters designed to 
> > "smooth out spikes" like bgwriter and vacuum delay, it helps to have really 
> > bad spikes to begin with.   There's a possibility that the parameters (and 
> > calculations) that work well for for a "steady-state" OLTP application are 
> > actually bad for an application with much more erratic usage, just as a high 
> > sort_mem is good for DSS and bad for OLTP.
> 
> I'm a little concerned that in an erratic, or even just a changing 
> environment there isn't going to be any set of values that are "correct".

I think this expresses my own thoughts most clearly, however: There have
been many good ideas expressed on this thread, though none of them,
including my own, are IMHO suitable for inclusion in 8.0, given the
stage of the release process we are now at.

***
Please give your support now to the addition of Neil's recent bgwriter
patch to the 8.0 release. It simplifies tuning, is proven to remove a
clear performance blockage, yet does so without changing the underlying
algorithm used by the bgwriter - so there is no case to answer along the
lines that this might not apply in some situations. Neil's bgwriter does
the same thing, just avoids holding a critical lock for longer than it
needs to.
***

I will happily discuss further ideas for 8.1 at a later stage.

I'll be around tomorrow for further discussion and better replies to
different individual points. Please excuse my slow answers during this
debate.

-- 
Best Regards, Simon Riggs



pgsql-hackers by date:

Previous
From: Thomas Hallgren
Date:
Subject: Re: Permissions within a function
Next
From: Bruce Momjian
Date:
Subject: Re: Port report: NetBSD 2.0 mac68k