Re: Default setting for enable_hashagg_disk (hash_mem)

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, David Rowley <dgrowleyml(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Default setting for enable_hashagg_disk (hash_mem)
Date: 2020-07-03 14:08:08
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-docs pgsql-hackers

On Thu, Jul 2, 2020 at 08:35:40PM -0700, Peter Geoghegan wrote:
> But the problem isn't really the hashaggs-that-spill patch itself.
> Rather, the problem is the way that work_mem is supposed to behave in
> general, and the impact that that has on hash aggregate now that it
> has finally been brought into line with every other kind of executor
> node. There just isn't much reason to think that we should give the
> same amount of memory to a groupagg + sort as a hash aggregate. The
> patch more or less broke an existing behavior that is itself
> officially broken. That is, the problem that we're trying to fix here
> is only a problem to the extent that the previous scheme isn't really
> operating as intended (because grouping estimates are inherently very
> hard). A revert doesn't seem like it helps anyone.
> I accept that the idea of inventing hash_mem to fix this problem now
> is unorthodox. In a certain sense it solves problems beyond the
> problems that we're theoretically obligated to solve now. But any
> "more conservative" approach that I can think of seems like a big
> mess.

Well, the bottom line is that we are designing features during beta.
People are supposed to be testing PG 13 behavior during beta, including
optimizer behavior. We don't even have a user report yet of a
regression compared to PG 12, or one that can't be fixed by increasing

If we add a new behavior to PG 13, we then have the pre-PG 13 behavior,
the pre-patch behavior, and the post-patch behavior. How are people
supposed to test all of that? Add to that that some don't even feel we
need a new behavior, which is delaying any patch from being applied.

Bruce Momjian <bruce(at)momjian(dot)us>

The usefulness of a cup is in its emptiness, Bruce Lee

In response to


Browse pgsql-docs by date

  From Date Subject
Next Message Justin Pryzby 2020-07-03 14:56:20 Re: Default setting for enable_hashagg_disk (hash_mem)
Previous Message Andrey Lizenko 2020-07-03 13:44:23 "Direct download" button is broken on

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2020-07-03 14:11:27 Re: TAP tests and symlinks on Windows
Previous Message Peter Eisentraut 2020-07-03 14:04:10 Re: warnings for invalid function casts