"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
What might be productive is picking up a group of parameters and thinking hard
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.
Ask me about EnterpriseDB's PostGIS support!
In response to
pgsql-hackers by date
|Next:||From: Gregory Stark||Date: 2008-05-31 19:36:54|
|Subject: Re: Overhauling GUCS|
|Previous:||From: Josh Berkus||Date: 2008-05-31 18:48:26|
|Subject: Re: Feedback on blog post about Replication Feature decision and its impact|