To: Carlos Moreno <moreno_pg@mochima.com>
cc: pgsql-performance@postgresql.org
Subject: Re: Feature Request --- was: PostgreSQL Performance Tuning 
In-reply-to: <463158DD.3060602@mochima.com> 
References: 
 <OFC96167D5.6BB63AC2-ON652572C9.003B5263-652572C9.003E4142@lntinfotech.com>
	<46310247.2050802@pinpointresearch.com>
	<463158DD.3060602@mochima.com>
Comments: In-reply-to Carlos Moreno <moreno_pg@mochima.com>
	message dated "Thu, 26 Apr 2007 21:58:53 -0400"
Date: Thu, 26 Apr 2007 22:49:13 -0400
Message-ID: <2679.1177642153@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Carlos Moreno <moreno_pg@mochima.com> writes:
> ...  But, wouldn't it make sense that the configure script
> determines the amount of physical memory and perhaps even do a HD
> speed estimate to set up defaults that are closer to a 
> performance-optimized
> configuration?

No.  Most copies of Postgres these days are executed on machines very
far away from where the code was built.  It's a little bit safer to
try to tune things at initdb time ... as indeed we already do.  But
the fundamental problem remains that we don't know that much about
how the installation will be used.  For example, the planner
configuration parameters turn out to have not that much to do with the
absolute speed of your drive, and a whole lot to do with the ratio
of the size of your database to the amount of RAM you've got; and the
ultimate size of the DB is one thing initdb certainly can't guess.

Also, there is an extremely good reason why Postgres will never be set
up to try to take over the whole machine by default: most of the
developers run multiple postmasters on their machines.

			regards, tom lane