Re: Overhauling GUCS - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Overhauling GUCS
Date
Msg-id 200806112300.m5BN0Dc13952@momjian.us
Whole thread Raw
In response to Re: Overhauling GUCS  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Overhauling GUCS
List pgsql-hackers
Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > Tom Lane wrote:
> >> * Can we build a "configuration wizard" to tell newbies what settings
> >> they need to tweak?
> 
> > That would trump all the other suggestions conclusively. Anyone good at 
> > expert systems?
> 
> How far could we get with the answers to just three questions:
> 
> * How many concurrent queries do you expect to have?
> 
> * How much RAM space are you willing to let Postgres use?
> 
> * How much "overhead" disk space are you willing to let Postgres use?
> 
> concurrent queries drives max_connections, obviously, and RAM space
> would drive shared_buffers and effective_cache_size, and both of them
> would be needed to size work_mem.  The third one is a bit weird but
> I don't see any other good way to set the checkpoint parameters.
> 
> If those aren't enough questions, what else must we ask?  Or maybe they
> aren't the right questions at all --- maybe we should ask "is this a
> dedicated machine or not" and try to extrapolate everything else from
> what we (hopefully) can find out about the hardware.

Having returned from Japan, I read through this thread.  It had lots of
ideas (new format for postgresql.conf, more/less comments in
postgresql.conf) but I didn't see any of the ideas getting a majority.

I think we do a good job of making many settings automatic (meaning no
one even sees them), but we don't to a great job of making the visible
settings easy to set, both in the process (no GUI) and in knowing the
proper value.

There are two ideas I did think had merit.  First, using ## for
system-supplied comments, so user comments would be easier to identify.
There might be value in doing that even if it were not helpful for
scripts.

The second idea is the idea of having one parameter depend on another. 
Not only could we do that for some of our existing parameters, but we
could have pseudo-parameters like concurrent_queries, memory_usage, and
extra_disk_space that could be at the top of postgresql.conf and then
affect the other settings.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: How to Sponsor a Feature
Next
From: Tom Lane
Date:
Subject: Adding more context to tuptoaster's elog messages