To: "David E. Wheeler" <david@kineticode.com>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>,  "Josh Berkus" <josh@agliodbs.com>,
	<pgsql-hackers@postgresql.org>
Subject: Re: Overhauling GUCS
In-Reply-To: <DFB26BD0-AD37-44F7-9255-BA78EC7E7FF8@kineticode.com> (David E.
	Wheeler's message of "Sat\, 31 May 2008 10\:51\:41 -0700")
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
References: <48409D1E.3070208@agliodbs.com> <16866.1212251015@sss.pgh.pa.us>
	<DFB26BD0-AD37-44F7-9255-BA78EC7E7FF8@kineticode.com>
From: Gregory Stark <stark@enterprisedb.com>
Organization: EnterpriseDB
Date: Sat, 31 May 2008 20:01:23 +0100
Message-ID: <87zlq6jo1o.fsf@oxford.xeocode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"David E. Wheeler" <david@kineticode.com> writes:

> I'd love to see these issues resolved. The current postgresql.conf is  way over
> the top. Might you have a better idea?

I don't think fiddling with surface issues like the formatting of the
postgresql.conf is productive. Hiding parameters because you don't think
beginners need them is only going to frustrate those people who do need to
adjust them.

What might be productive is picking up a group of parameters and thinking hard
about what they mean in terms of user-visible real-world effects. If they can
be recast in terms of behaviour the user wants instead of internal
implementation details then that would translate into a massive simplification
as well as being easier to explain to users.

I think we do a pretty good job of this already. Witness things like
effective_cache_size -- imagine if this were "nested_loop_cache_hit_rate" for
example, good luck figuring out what to set it to.

The vacuum cost delay factors are probably ripe for such a recast though. I
think we need just one parameter "vacuum_io_bandwidth" or something like that.
The bgwriter parameters might also be a candidate but I'm less certain.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's PostGIS support!