Re: Add enable_groupagg GUC parameter to control GroupAggregate usage

Richard Guo <guofenglinux@gmail.com>

From: Richard Guo <guofenglinux@gmail.com>
To: Tatsuro Yamada <tatsuro.yamada@ntt.com>
Cc: Tatsuro Yamada <yamatattsu@gmail.com>, David Rowley <dgrowleyml@gmail.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2026-07-07T06:47:21Z
Lists: pgsql-hackers

Attachments

On Mon, Jun 29, 2026 at 7:02 PM Tatsuro Yamada <tatsuro.yamada@ntt.com> wrote:
> Since the enable_groupagg parameter also affects SetOp, Unique, and
> other nodes, I've created documentation patches to clarify this. I'm attaching
> them to this email. They apply on top of your v4 patch.

I've thought it over, and I'm inclined to leave the docs as they are.

My main concern is consistency with the surrounding parameters.  All
of the other enable_* GUCs are documented conceptually rather than by
the specific node types they affect, and none of them enumerate the
nodes you'd see in EXPLAIN.  Unique and SetOp are really EXPLAIN
labels rather than user-facing concepts, and I'd argue the existing
wording already covers them, since sort-based Unique and sorted SetOp
are both forms of sort-based grouping.

Similarly, enable_hashagg has covered hash-based SetOp for a long time
without us documenting it, which is the same convention at work.  I'd
rather not add that now just to match the new parameter.

Attached is a rebased patch to make cfbot work again.

- Richard