Re: Default setting for enable_hashagg_disk

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Default setting for enable_hashagg_disk
Дата
Msg-id CAKFQuwYya1+My6rDxHO1O4Eg=1c3bFdy42LcHKRiEf_E7cBR+A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Default setting for enable_hashagg_disk  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
On Fri, Jul 10, 2020 at 6:43 PM David Rowley <dgrowleyml@gmail.com> wrote:
On Sat, 11 Jul 2020 at 13:36, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> If we add a setting that defaults to work_mem then the benefit is severely reduced.  You still have to modify individual queries, but the change can simply be more targeted than changing work_mem alone.

I think the idea is that this is an escape hatch to allow users to get
something closer to what PG12 did, but only if they really need it.  I
can't quite understand why we need to leave the escape hatch open and
push them halfway through it.  I find escape hatches are best left
closed until you really have no choice but to use them.


The escape hatch dynamic is "the user senses a problem, goes into their query, and modifies some GUCs to make the problem go away".  As a user I'd much rather have the odds of my needing to use that escape hatch reduced - especially if that reduction can be done without risk and without any action on my part.

It's like having someone in a box right now, and then turning up the heat.  We can give them an opening to get out of the box if they need it but we can also give them A/C.  For some the A/C may be unnecessary, but also not harmful,  while a smaller group will stay in the margin, while for the others it's not enough and use the opening (which they would have done anyway without the A/C).

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Default setting for enable_hashagg_disk
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Default setting for enable_hashagg_disk