Skip site navigation (1) Skip section navigation (2)

Re: Overhauling GUCS

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Josh Berkus" <josh(at)agliodbs(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Overhauling GUCS
Date: 2008-05-31 19:01:23
Message-ID: 87zlq6jo1o.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
"David E. Wheeler" <david(at)kineticode(dot)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!

In response to

Responses

pgsql-hackers by date

Next:From: Gregory StarkDate: 2008-05-31 19:36:54
Subject: Re: Overhauling GUCS
Previous:From: Josh BerkusDate: 2008-05-31 18:48:26
Subject: Re: Feedback on blog post about Replication Feature decision and its impact

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group