Re: Default setting for enable_hashagg_disk
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <pgsql@j-davis.com>, Peter Geoghegan <pg@bowt.ie>, Alvaro Herrera <alvherre@2ndquadrant.com>, David Rowley <dgrowleyml@gmail.com>, Andres Freund <andres@anarazel.de>, Bruce Momjian <bruce@momjian.us>, Robert Haas <robertmhaas@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Melanie Plageman <melanieplageman@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-07-19T11:38:37Z
Lists: pgsql-hackers, pgsql-docs
Greetings, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > Jeff Davis <pgsql@j-davis.com> writes: > > On Fri, 2020-07-17 at 18:38 -0700, Peter Geoghegan wrote: > >> There is also the separate question of what to do about the > >> hashagg_avoid_disk_plan GUC (this is a separate open item that > >> requires a separate resolution). Tom leans slightly towards removing > >> it now. Is your position about the same as before? > > > Yes, I think we should have that GUC (hashagg_avoid_disk_plan) for at > > least one release. > > You'e being optimistic about it being possible to remove a GUC once > we ship it. That seems to be a hard sell most of the time. Agreed. > I'm honestly a bit baffled about the level of fear being expressed > around this feature. We have *frequently* made changes that would > change query plans, perhaps not 100.00% for the better, and never > before have we had this kind of bikeshedding about whether it was > necessary to be able to turn it off. I think the entire discussion > is way out ahead of any field evidence that we need such a knob. > In the absence of evidence, our default position ought to be to > keep it simple, not to accumulate backwards-compatibility kluges. +100 > (The only reason I'm in favor of heap_mem[_multiplier] is that it > seems like it might be possible to use it to get *better* plans > than before. I do not see it as a backwards-compatibility knob.) I still don't think a hash_mem-type thing is really the right direction to go in, even if making a distinction between memory used for sorting and memory used for hashing is, and I'm of the general opinion that we'd be thinking about doing something better and more appropriate- except for the fact that we're talking about adding this in during beta. In other words, if we'd stop trying to shoehorn something in, which we're doing because we're in beta, we'd very likely be talking about all of this in a very different way and probably be contemplating something like a query_mem that provides for an overall memory limit and which favors memory for hashing over memory for sorting, etc. Thanks, Stephen
Commits
-
Add hash_mem_multiplier GUC.
- d6c08e29e7bc 14.0 landed
- 78530c8e7a5a 13.0 landed
-
HashAgg: use better cardinality estimate for recursive spilling.
- 3a232a3183d5 13.0 landed
- 9878b643f37b 14.0 landed
-
Remove hashagg_avoid_disk_plan GUC.
- bcbf9446a298 14.0 landed
- 5a6cc6ffa914 13.0 landed
-
Doc fixup for hashagg_avoid_disk_plan GUC.
- d33f33539d7f 13.0 landed
- 7ce461560159 14.0 landed
-
Rework HashAgg GUCs.
- 13e0fa7ae50c 13.0 landed
- 92c58fd94801 14.0 landed
-
Disk-based Hash Aggregation.
- 1f39bce02154 13.0 cited
-
Implement partition-wise grouping/aggregation.
- e2f1eb0ee30d 11.0 cited
-
Defer creation of partially-grouped relation until it's needed.
- 4f15e5d09de2 11.0 cited