On Fri, Nov 17, 2017 at 1:22 PM, Peter Geoghegan <p...@bowt.ie> wrote: > Right. The ability for sorts to do well with less memory is really > striking these days. And though I didn't mean to seriously suggest it, > a hash_mem GUC does seem like it solves some significant problems > without much risk. I think it should be hash_mem, not sort_mem, > because hashing seems more like the special case among operations that > consume work_mem, and because sort_mem is already the old name for > work_mem that is still accepted as a work_mem alias, and because > hash_mem avoids any confusion about whether or not CREATE INDEX uses > the new GUC (it clearly does not).
Hmm. I wonder if you are correct that hashing is the special case. Hashing and sorting are of course the two main operations -- but there's materialize and anything else that uses a CTE, and maybe other stuff I'm not thinking about right now. You might be right that hash is the one where it really matters, but it's probably worth a bit more reflection on where it matters most and for what reasons. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
