On Sat, Apr 30, 2016 at 3:23 PM, Bruce Momjian <br...@momjian.us> wrote: > Yes, this needs updating. My point is that there is a whole lot of > things we don't talk about in this area, and should, but I would like it > to be of a consistent level of detail for all areas of performancce.
I think that we need to do better generally too, but the existing handling of performance, such as it is, is not consistent in the level of detail it goes into. For example, we give far more advice about setting the value of commit_delay than setting the value of work_mem, even though that's clearly a niche topic in comparison. You can say the same thing about effective_io_concurrency. 95%+ of all users don't use either setting, making that documentation irrelevant to them. I think that this is simply because it was hard to make a good recommendation about work_mem, but that's now less true overall. We don't like equivocating, so we said only the absolute minimum. ISTM that the area that needs the most attention is planner stuff, and query workspace memory stuff (e.g. work_mem, temp files). work_mem and maintenance_work_mem seem like good places to start adding more practical advise, particularly given we can avoid mentioning sorting or hashing, and still add value. Maybe there is a place to emphasize this change in the release notes. I don't really want to make it about the external sort feature, though, because enabling higher work_mem settings by making sure that does not disadvantage external sorts is as much about enabling HashAggregates as it is about enabling internal sorts. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
