On Sat, Apr 30, 2016 at 3:23 PM, Bruce Momjian <bruce@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