Re: Initial release notes created for 9.6

On Thu, May 5, 2016 at 7:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Geoghegan <pg(at)heroku(dot)com> writes:
>> I think that there could stand to be some consolidation among the
>> items that I authored.
>
> After thinking a bit, I merged all the abbreviated-keys stuff including
> the ordered-set-aggregate item. Let me know if that seems wrong.

I didn't imagine going so far as putting the ordered-set aggregate
item in there too, but I actually think that that's an improvement.

>> If it were up to me, I'd consolidate the two, and provide a
>> higher-level description. I'd probably say something about CPU cache
>> efficiency, and how the distinction between external sorts and
>> internal sorts has been significantly softened. I'd also mention that
>> the new approach can make better use of larger work_mem settings, and
>> great temp_tablespaces I/O capacity, which Bruce agreed warranted
>> notice in the release notes [1].
>
> Meh. The release notes are not the place for that kind of detail,
> mainly because nobody will look at old release notes when searching
> for info.

I agree with this, but was concerned that better advice around sizing
work_mem in the documentation would not be accepted.

> Also, I saw that you already had a rather long discussion
> about this associated with the replacement_sort_tuples GUC (which
> *is* a reasonable place for it). My intention in providing the link
> was so people could consult that info easily --- but I added a few
> more words to point out explicitly that there was more info there.

The documentation provides only a very weak endorsement of the idea
that increasing maintenance_work_mem improves the performance of
*anything*, and it only does so once (work_mem doesn't even get that
much). It's easy to fail to notice that as an expert.

I actually think of the 9.6 work on external sorting as fixing a
problem peculiar to one particular consumer of work_mem as much as
anything else (the problem of weird CPU cache sensitivity). So, my
concern is fairly high-level. I want to communicate two ideas to
users:

1. Consider that your previous experiences with sizing work_mem might
be made obsolete by 9.6. You should be able to safely increase
work_mem with the expectation that doing so will more or less improve
performance across the board, or at least not hurt things. There are
some caveats, of course, but they're fairly limited, and even obvious
(e.g., don't let Postgres do a significant amount of swapping). We
don't need to equivocate, which ISTM is what we did when discussing
these settings before now.

If you think that's unfair, consider how terse the docs are when
discussing sizing work_mem compared to settings like commit_delay and
effective_io_concurrency.

2. A fast temp_tablespaces setting becomes more useful, particularly
when adding more memory stops helping.

I'm not sure that this even needs to be made about the external
sorting stuff. I'm not attached to communicating this to users in any
particular way.

--
Peter Geoghegan