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 work_mem. 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 <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
