Re: Overhauling GUCS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Overhauling GUCS
Date
Msg-id 7473.1212625397@sss.pgh.pa.us
Whole thread Raw
In response to Re: Overhauling GUCS  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Overhauling GUCS  (Aidan Van Dyk <aidan@highrise.ca>)
Re: Overhauling GUCS  (Steve Atkins <steve@blighty.com>)
Re: Overhauling GUCS  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Re: Overhauling GUCS  (Robert Lor <Robert.Lor@Sun.COM>)
Re: Overhauling GUCS  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Re: Overhauling GUCS  (Peter Eisentraut <peter_e@gmx.net>)
Re: Overhauling GUCS  (Bruce Momjian <bruce@momjian.us>)
Re: Overhauling GUCS  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: rfc: add pg_dump options to dump output
Next
From: Tom Lane
Date:
Subject: Re: Overhauling GUCS