Re: Add enable_groupagg GUC parameter to control GroupAggregate usage

On Thu, Jun 25, 2026 at 8:05 AM Richard Guo <guofenglinux(at)gmail(dot)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