Re: Default setting for enable_hashagg_disk

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Default setting for enable_hashagg_disk
Дата
Msg-id 571473265c5d5309f4012855ebd2131c136073ab.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Default setting for enable_hashagg_disk  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Default setting for enable_hashagg_disk  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Default setting for enable_hashagg_disk  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
On Sat, 2020-07-18 at 14:30 -0400, Tom Lane wrote:
> You'e being optimistic about it being possible to remove a GUC once
> we ship it.  That seems to be a hard sell most of the time.

If nothing else, a repeat of this thread in a year or two to discuss
removing a GUC doesn't seem appealing.

> I think the entire discussion
> is way out ahead of any field evidence that we need such a knob.
> In the absence of evidence, our default position ought to be to
> keep it simple, not to accumulate backwards-compatibility kluges.

Fair enough. I think that was where Stephen and Amit were coming from,
as well.

What is your opinion about pessimizing the HashAgg disk costs (not
affecting HashAgg plans expected to stay in memory)? Tomas Vondra
presented some evidence that Sort had some better IO patterns in some
cases that weren't easily reflected in a principled way in the cost
model.

That would lessen the number of changed plans, but we could easily
remove the pessimization without controversy later if it turned out to
be unnecessary, or if we further optimize HashAgg IO.

Regards,
    Jeff Davis





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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Wrong results from in_range() tests with infinite offset
Следующее
От: Tom Lane
Дата:
Сообщение: Re: renaming configure.in to configure.ac