Re: Add enable_groupagg GUC parameter to control GroupAggregate usage

On Thu, Jun 25, 2026 at 8:05 AM Richard Guo <guofenglinux@gmail.com> wrote:
> I rebased your last patch and made some changes.  Attached is what I
> ended up with.

I looked into the AGG_MIXED case some more, and I don't think the v3
patch handles it correctly.  I'd assumed an AGG_MIXED plan always does
some sorted grouping, but that's not true.  For the common cube/rollup
queries the grouping sets always include the empty set, which can't be
hashed, so even the maximally-hashed plan comes out as AGG_MIXED.
Disabling it under enable_groupagg therefore penalizes the very plan
we want.

To recap how grouping sets are costed: create_groupingsets_path loops
over the rollups and calls cost_agg once per rollup.  The first call
gets the path's overall strategy (AGG_MIXED for a mixed plan); the
rest come through as AGG_HASHED or AGG_SORTED, one per rollup, with
their disabled_nodes summed into the path.  So an AGG_MIXED plan's
sorted grouping shows up in the per-rollup AGG_SORTED calls, not in
the AGG_MIXED call itself.

And the empty grouping set is really computed like AGG_PLAIN, with no
hash table and no sort, so it shouldn't bump disabled_nodes at all.
It reaches cost_agg with numGroupCols == 0, which makes it easy to
tell apart.  So in the attached patch AGG_MIXED is disabled only by
enable_hashagg, and AGG_SORTED is disabled by enable_groupagg only
when numGroupCols > 0.  That also lets the tests in groupingsets.sql
use enable_groupagg, which they couldn't before.

- Richard