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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2008-06-04 03:49:21|
|Subject: Re: rfc: add pg_dump options to dump output |
|Previous:||From: Andrew Sullivan||Date: 2008-06-04 03:20:11|
|Subject: Re: Core team statement on replication in PostgreSQL|