Merlin Moncure wrote:
I would prefer to see the annotated performance oriented .conf settings to be written in terms of trade offs (too low? X too high? Y setting in order to get? Z). For example, did you know that if crank max_locks_per_transaction you also increase the duration of every query that hits pg_locks() -- well, now you do :-).
You can't do this without providing more context and tools for people to measure their systems. At PGCon last week, I presented a talk specifically about tuning shared_buffers and the checkpoint settings. What's come out of my research there is that you can stare at the data in pg_buffercache and pg_stat_bgwriter and classify systems based on the distribution of usage counts in their buffer cache on how the background writer copes with that. The right style of tuning to apply is dependent on whether someone has a high proportion of buffers with a usage count >=2. A tuning guide that actually covered that in enough detail to be an improvement over what is in the "Tuning Your PostgreSQL Server" would be overwhelming large, defeating the purpose of that document--providing a fairly bite-size guide.
-- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@xxxxxxxxxxxxxxx www.2ndQuadrant.us -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
