Re: Default setting for enable_hashagg_disk (hash_mem)

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Default setting for enable_hashagg_disk (hash_mem)
Дата
Msg-id 20200707171216.jqxrld2jnxwf5ozv@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Default setting for enable_hashagg_disk (hash_mem)  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Default setting for enable_hashagg_disk (hash_mem)  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
Hi,

On 2020-07-03 10:08:08 -0400, Bruce Momjian wrote:
> 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.

I think it makes no too much sense to plan invent something like
hash_mem for v13, it's clearly too much work. That's a seperate
discussion from having something like it for v14.


> 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.

I posted a repro, and no you can't fix it by increasing work_mem without
increasing memory usage in the whole query / all queries.


> 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?

I don't really buy this as a problem. It's not like the pre-13 behaviour
would be all new. It's how PG has behaved approximately forever.


My conclusion about this topic is that I think we'll be doing our users
a disservice by not providing an escape hatch, but that I also don't
have the energy / time to fight for it further. This is a long thread
already, and I sense little movement towards a conclusion.

Greetings,

Andres Freund



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

Предыдущее
От: Thom Brown
Дата:
Сообщение: Re: [HACKERS] Look-behind regular expressions
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: OpenSSL 3.0.0 compatibility