| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Default setting for enable_hashagg_disk |
| Date: | 2020-07-09 06:47:43 |
| Message-ID: | 99b047386525b87df1e611335c2e57a6cdef346b.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs pgsql-hackers |
On Wed, 2020-07-08 at 10:00 -0400, Stephen Frost wrote:
> That HashAgg previously didn't care that it was going wayyyyy over
> work_mem was, if anything, a bug.
I think we all agree about that, but some people may be depending on
that bug.
> Inventing new GUCs late in the
> cycle like this under duress seems like a *really* bad idea.
Are you OK with escape-hatch GUCs that allow the user to opt for v12
behavior in the event that they experience a regression?
The one for the planner is already there, and it looks like we need one
for the executor as well (to tell HashAgg to ignore the memory limit
just like v12).
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2020-07-09 14:03:30 | Re: Default setting for enable_hashagg_disk |
| Previous Message | Stephen Frost | 2020-07-08 14:00:37 | Re: Default setting for enable_hashagg_disk |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabien COELHO | 2020-07-09 06:57:01 | Re: pgbench - add pseudo-random permutation function |
| Previous Message | Peter Eisentraut | 2020-07-09 06:43:24 | Re: OpenSSL 3.0.0 compatibility |