Re: Overhauling GUCS

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <gsmith(at)gregsmith(dot)com>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, Decibel! <decibel(at)decibel(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: Overhauling GUCS
Date: 2008-06-06 20:24:28
Message-ID: 200806061624.29105.xzilla@users.sourceforge.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2008-06-06 20:30:33 Re: Overhauling GUCS
Previous Message Jignesh K. Shah 2008-06-06 20:24:19 Re: Proposal: New LWLockmode LW_OWNER