From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@postgresql.org
Subject: Re: Overhauling GUCS
Date: Fri, 6 Jun 2008 14:39:31 +0200
User-Agent: KMail/1.9.9
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>,
	Greg Smith <gsmith@gregsmith.com>,
	Andreas Pflug <pgadmin@pse-consulting.de>,
	"Decibel!" <decibel@decibel.org>, Josh Berkus <josh@agliodbs.com>
References: <48409D1E.3070208@agliodbs.com> <48472E47.7030701@dunslane.net>
	<7473.1212625397@sss.pgh.pa.us>
In-Reply-To: <7473.1212625397@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200806061439.32335.peter_e@gmx.net>

Am Donnerstag, 5. Juni 2008 schrieb Tom Lane:
> 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?

This is surely a good start.  We could optimize this even more by saying, disk 
space is cheap, so let's just use a much higher default setting for 
checkpoint_segments.  (If PostgreSQL is installed but not actually used, not 
all the space is actually going to be used anyway.)  Then, increase 
max_connections a bit; that should be OK for most users.  Then you are left 
with the memory settings, and those need kernel tuning in most cases, so any 
automation tool loses.  Hmm.