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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
