Date: Tue, 3 Jun 2008 23:48:24 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: Paul van den Bogaard <Paul.Vandenbogaard@Sun.COM>
cc: josh@agliodbs.com, pgsql-hackers@postgresql.org
Subject: Re: Overhauling GUCS
In-Reply-To: <0B854D92-C5C2-4138-A0FE-F81892A33869@sun.com>
Message-ID: <Pine.GSO.4.64.0806032324550.10282@westnet.com>
References: <48409D1E.3070208@agliodbs.com> <484418D9.5040608@sun.com>
	<Pine.GSO.4.64.0806021227100.4018@westnet.com>
	<200806021106.05833.josh@agliodbs.com>
	<0B854D92-C5C2-4138-A0FE-F81892A33869@sun.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 3 Jun 2008, Paul van den Bogaard wrote:

> So overhauling the GUC parameters is one step, but adding proper 
> instrumentation in order to really measure the impact of the new setting 
> is necessary too.

Correct, but completely off-topic regardless.  One problem to be solved 
here is to take PostgreSQL tuning from zero to, say, 50% automatic. 
Wander the user lists for a few months; the number of completely 
misconfigured systems out there is considerable, partly because the 
default values for many parameters are completely unreasonable for modern 
hardware and there's no easy way to improve on that without someone 
educating themselves.  Getting distracted by the requirements of the 
high-end systems will give you a problem you have no hope of executing in 
a reasonable time period.

By all means bring that up as a separate (and much, much larger) project: 
"Database Benchmarking and Sensitivity Analysis of Performance Tuning 
Parameters" would make a nice PhD project for somebody, and there's 
probably a good patent in there somewhere.  Even if you had such a tool, 
it wouldn't be usable by non-experts unless the mundate GUC generation 
issues are dealt with first, and that's where this is at right now.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD