From: Steve Atkins <steve@blighty.com>
To: PostgreSQL Developers <pgsql-hackers@postgresql.org>
Subject: Re: Overhauling GUCS
Date: Wed, 4 Jun 2008 18:20:49 -0700
Message-ID: <448BD875-FE20-4985-92CD-DFF6FC0641D3@blighty.com> (raw)
In-Reply-To: <7473.1212625397@sss.pgh.pa.us>
References: <48409D1E.3070208@agliodbs.com>
<200806010032.53337.peter_e@gmx.net>
<Pine.GSO.4.64.0806020452220.26912@westnet.com>
<17932.1212415926@sss.pgh.pa.us>
<20080604131810.GH65238@decibel.org>
<4846A483.8000001@pse-consulting.de>
<Pine.GSO.4.64.0806041045520.2258@westnet.com>
<29525.1212613052@sss.pgh.pa.us>
<48472E47.7030701@dunslane.net>
<7473.1212625397@sss.pgh.pa.us>
On Jun 4, 2008, at 5:23 PM, 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.
I'd be interested in putting together a framework+GUI client to do this
cleanly in a cross-platform (Windows, Linux, Solaris, OS X as a bare
minimum) sort of way, if no-one else already has such a thing.
A framework doesn't get you all the way there, but it makes it a
whole lot easier to work on what base data and information you
need, and how easy it is to map pgsql-performance and #postgresql
gut feel onto something more algorithmic.
Cheers,
Steve
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: steve@blighty.com
Subject: Re: Overhauling GUCS
In-Reply-To: <448BD875-FE20-4985-92CD-DFF6FC0641D3@blighty.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox