Horton

Re: Default setting for enable_hashagg_disk (hash_mem)

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Amit Kapila <amit.kapila16@gmail.com>, Bruce Momjian <bruce@momjian.us>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, David Rowley <dgrowleyml@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, pgsql-hackers@postgresql.org
Date: 2020-07-07T05:02:39Z
Lists: pgsql-hackers, pgsql-docs 
On Mon, Jul 06, 2020 at 09:57:08PM -0700, Jeff Davis wrote:
> > I think that we should offer something like hash_mem that can work as
> > a multiple of work_mem, for the reason that Justin mentioned
> > recently.
> > This can be justified as something that more or less maintains some
> > kind of continuity with the old design.
> 
> Didn't Justin argue against using a multiplier?
> https://postgr.es/m/20200703024649.GJ4107@telsasoft.com

I recanted.
https://www.postgresql.org/message-id/20200703145620.GK4107@telsasoft.com

-- 
Justin

Commits

  1. Add hash_mem_multiplier GUC.

  2. HashAgg: use better cardinality estimate for recursive spilling.

  3. Remove hashagg_avoid_disk_plan GUC.

  4. Doc fixup for hashagg_avoid_disk_plan GUC.

  5. Rework HashAgg GUCs.

  6. Disk-based Hash Aggregation.

  7. Implement partition-wise grouping/aggregation.

  8. Defer creation of partially-grouped relation until it's needed.