"David E. Wheeler" <[EMAIL PROTECTED]> 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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers