Re: Overhauling GUCS - Mailing list pgsql-hackers

On Friday 06 June 2008 08:35:00 Peter Eisentraut wrote:
> Am Mittwoch, 4. Juni 2008 schrieb Tom Lane:
> > * Can we present the config options in a more helpful way (this is 99%
> > a documentation problem, not a code problem)?
>
> ack
>
> > * Can we build a "configuration wizard" to tell newbies what settings
> > they need to tweak?
>
> Some questions to clarify this:
>
> - What settings do "newbies" (or anyone else) typically need to change?
> Please post a list.
>

i do have a defined set (sort of a "top ten you need to know") that i tell 
people about in my postgres 101 tutorials... off the top of my head it looks 
like this:

shared_buffers
effective_cache_size
default_stats_target
work_mem
maintainance_work_mem
listen_address
max_connections
the fsm parameters
checkpoint_segements
random_page_cost

i think others close to the list are constraint_exclusion (unless it defaults 
to on now), max_prepared_transactions (set it to 0 unless you use it... i may 
stop recommending this after noticing its effects on max # system locks 
allowed), and then the logging parameters (which is to say, you need to set 
up logging that works, however you want to do it). 

There are a couple more that might go on the list, like synchronous_commit, 
but its on the fence for now. 

> - What values would you set those settings to?  Please provide a
> description for arriving at a value, which can later be transformed into
> code.  Note that in some cases, not even the documentation provides more
> than handwaving help.
>

I can provide this if you want, will need to look over my notes. one issue 
we've faced in the past with this is something like shared_buffers, where the 
settings is based on 1) dedicated server?, 2) available ram, 3) amount of 
red/write traffic, 4) disk subsystem.  Those types of input are hard to 
quantify in code. 

> - If we know better values, why don't we set them by default?
>

There is a saying, something like "The accumulation of annecdotes is not 
data".  Well, we seem to have a high bar on what proof we need to actually 
change a default GUC settings. default_statistics_target is a prime example, 
where almost no one i know has ever recommended 10 as a default, or suggests 
setting it to 10 as an way to improve performance, but the effort to get it 
changed to something more reasonable has been monumental. 

> Another orthogonal stumbling block on the way to making all of this
> automatic is that the surely criticial shared_buffers setting will in any
> useful configuration require messing around with kernel settings that no
> PostgreSQL tool can really help with.

yep.  seems it might be possible to just compare the shared_buffer setting 
with the kernel parameters before making the change though... not sure in 
which way you would slant the output though. 

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL