Re: PG 13 release notes, first draft

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: PG 13 release notes, first draft
Дата
Msg-id CAKFQuwaXtpnvoppHLy8U0N6-SPBVrVszrDboaG9AgH7QGp_TQA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PG 13 release notes, first draft  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: PG 13 release notes, first draft  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Wednesday, July 29, 2020, Peter Geoghegan <pg@bowt.ie> wrote:
On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian <bruce@momjian.us> wrote:
> > There should be a note about this in the Postgres 13 release notes,
> > for the usual reasons. More importantly, the "Allow hash aggregation
> > to use disk storage for large aggregation result sets" feature should
> > reference the new GUC directly. Users should be advised that the GUC
> > may be useful in cases where they upgrade and experience a performance
> > regression linked to slower hash aggregation. Just including a
> > documentation link for the GUC would be very helpful.
>
> I came up with the attached patch.

I was thinking something along like the following (after the existing
sentence about avoiding hash aggs in the planner):

If you find that hash aggregation is slower than in previous major
releases of PostgreSQL, it may be useful to increase the value of
hash_mem_multiplier. This allows hash aggregation to use more memory
without affecting competing query operations that are generally less
likely to put any additional memory to good use.


How about adding wording for GROUP BY as well to cater to users who are more comfortable thinking in terms of SQL statements instead of execution plans?

David J.

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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.