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
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 |