RE: Add enable_groupagg GUC parameter to control GroupAggregate usage

From: Tatsuro Yamada <tatsuro(dot)yamada(at)ntt(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Tatsuro Yamada <yamatattsu(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: Add enable_groupagg GUC parameter to control GroupAggregate usage
Date: 2026-06-29 10:02:29
Message-ID: TY4P301MB12997F863B7B51A520E02ABC9EE82@TY4P301MB1299.JPNP301.PROD.OUTLOOK.COM
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Richard,

> Yeah, I think so. The v4 patch actually already did that. You can
> find these changes in create_setop_path(), create_unique_path(), and
> cost_group().

Thank you for the clarification. I've reviewed the v4 patch and confirmed
that it already covers SetOp, Unique, Group, etc.
I ran make installcheck in my environment and all tests passed without
errors.

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.

- 0001 patch: This improves the documentation for the enable_groupagg
parameter so that users can more easily understand which operations it
affects. If you agree with the changes, I'd like to post an updated patch
that integrates this into v4.

- 0002 patch: This provides a similar improvement for the enable_hashagg
parameter documentation. Since it concerns enable_hashagg, I'm happy
to move this to a separate thread if you prefer.

Best Regards,
Tatsuro Yamada

> -----Original Message-----
> From: Richard Guo <guofenglinux(at)gmail(dot)com>
> Sent: Friday, June 26, 2026 3:26 PM
> To: Tatsuro Yamada(山田達朗) <tatsuro(dot)yamada(at)ntt(dot)com>
> Cc: Tatsuro Yamada <yamatattsu(at)gmail(dot)com>; David Rowley
> <dgrowleyml(at)gmail(dot)com>; Ashutosh Bapat
> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>; pgsql-hackers(at)lists(dot)postgresql(dot)org
> Subject: Re: Add enable_groupagg GUC parameter to control
> GroupAggregate usage
>
> On Thu, Jun 25, 2026 at 6:12 PM Tatsuro Yamada <tatsuro(dot)yamada(at)ntt(dot)com>
> wrote:
> > It sounds like there are several plan nodes that could be covered by this
> GUC
> > (such as SetOp, sort-based Unique for DISTINCT, semijoin uniqueification,
> > and Group nodes). Do you think we should cover all of them before the
> patch
> > would be considered complete enough for commit?
>
> Yeah, I think so. The v4 patch actually already did that. You can
> find these changes in create_setop_path(), create_unique_path(), and
> cost_group().
>
> > I'd be interested to hear your thoughts on how best to proceed, and
> whether
> > dividing the work into smaller pieces would make sense.
>
> It seems that the scope of the regression test changes isn't too
> large, so I think keeping them in one patch is fine.
>
> - Richard

Attachment Content-Type Size
0001-doc-Clarify-enable_groupagg-also-covers-Unique-and-S.patch application/octet-stream 1.2 KB
0002-doc-Clarify-enable_hashagg-also-covers-hash-based-Se.patch application/octet-stream 1.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christoph Berg 2026-06-29 10:04:13 [PATCH] Document wal_compression=on
Previous Message Tatsuo Ishii 2026-06-29 09:37:30 Re: Row pattern recognition