Re: PG 13 release notes, first draft

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 13 release notes, first draft
Date: 2020-07-30 03:43:24
Message-ID: CAKFQuwaXtpnvoppHLy8U0N6-SPBVrVszrDboaG9AgH7QGp_TQA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, July 29, 2020, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:

> On Wed, Jul 29, 2020 at 6:30 PM Bruce Momjian <bruce(at)momjian(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-07-30 04:05:02 Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
Previous Message Peter Geoghegan 2020-07-30 03:35:08 Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.