Re: Initial release notes created for 9.6 - Mailing list pgsql-hackers
From | Peter Geoghegan |
---|---|
Subject | Re: Initial release notes created for 9.6 |
Date | |
Msg-id | CAM3SWZSOOUY3eqUZiC32he-FxycCxfV5rKots-8OF20rZgcx7g@mail.gmail.com Whole thread Raw |
In response to | Re: Initial release notes created for 9.6 (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
On Thu, May 5, 2016 at 7:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Geoghegan <pg@heroku.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
pgsql-hackers by date: