From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Default setting for enable_hashagg_disk |
Date: | 2020-04-09 18:25:56 |
Message-ID: | ff9fdc4072e3be732ba9fd582f27982daecc4e43.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
On Thu, 2020-04-09 at 12:24 -0500, Justin Pryzby wrote:
> Also.. there's no such thing as enable_groupagg? Unless I've been
> missing out
> on something.
I thought about adding that, and went so far as to make a patch. But it
didn't seem right to me -- the grouping isn't what takes the time, it's
the sorting. So what would the point of such a GUC be? To disable
GroupAgg when the input data is already sorted? Or a strange way to
disable Sort?
> Because HashAgg plans which used to run fine (because they weren't
> prevented
> from overflowing work_mem) might now run poorly after spilling to
> disk (because
> of overflowing work_mem).
It's probably worth a mention in the release notes, but I wouldn't word
it too strongly. Typically the performance difference is not a lot if
the workload still fits in system memory.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2020-04-09 19:26:36 | Re: Default setting for enable_hashagg_disk |
Previous Message | Justin Pryzby | 2020-04-09 17:24:04 | Re: Default setting for enable_hashagg_disk |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2020-04-09 18:26:45 | Re: cleaning perl code |
Previous Message | Alexey Kondratov | 2020-04-09 18:16:05 | Re: [HACKERS] make async slave to wait for lsn to be replayed |