On Mon, Jun 22, 2020 at 10:52:37AM -0400, Robert Haas wrote: > On Wed, Jun 10, 2020 at 2:39 PM Jeff Davis <pg...@j-davis.com> wrote: > > The behavior in v13 master is, by default, analagous to Sort or > > anything else that adapts at runtime to spill. If we had spillable > > HashAgg the whole time, we wouldn't be worried about #2 at all. But, > > out of conservatism, I am trying to accommodate users who want an > > escape hatch, at least for a release or two until users feel more > > comfortable with disk-based HashAgg. > > > > Setting enable_hash_disk=false implements 2(a). This name apparently > > causes confusion, but it's hard to come up with a better one because > > the v12 behavior has nuance that's hard to express succinctly. I don't > > think the names you suggested quite fit, but the idea to use a more > > interesting GUC value might help express the behavior. Perhaps making > > enable_hashagg a ternary "enable_hashagg=on|off|avoid_disk"? The word > > "reject" is too definite for the planner, which is working with > > imperfect information. > > > > In master, there is no explicit way to get 2(b), but you can just set > > work_mem higher in a lot of cases. If enough people want 2(b), I can > > add it easily. Perhaps hashagg_overflow=on|off, which would control > > execution time behavior? > > don't think we do, so I'm very skeptical of the idea that we need 2 > just for this feature. That doesn't feel scalable. I think the right > number is 0 or 1, and if it's 1, very few people should be changing > the default. If anything else is the case, then IMHO the feature isn't > ready to ship.
This was addressed in 92c58fd94801dd5c81ee20e26c5bb71ad64552a8 https://wiki.postgresql.org/index.php?title=PostgreSQL_13_Open_Items&diff=34994&oldid=34993 -- Justin