On Fri, Nov 17, 2017 at 1:22 PM, Peter Geoghegan <pg@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