Fix constant GROUP BY on empty input

[krylosov-aa]

Fixes #2025

What does this PR do?

With optimizer=off and gp_enable_multiphase_agg=on, grouping by a constant can return a row when the input is empty. For example, SELECT count(*) FROM t GROUP BY 'x'::text returns one row with zero instead of no rows.

The planner removes constant grouping keys, then treats the final aggregation step as if the query had no GROUP BY.

This change checks the original GROUP BY clause when choosing the aggregation strategy. Empty input now returns no rows even when all grouping keys have been removed. It also fixes an assertion failure for constant GROUP BY without aggregate functions.

Type of Change

• Bug fix (non-breaking change)

Test Plan

Added gp_group_by_constant. It fails before the fix and passes after it. The test covers both planners, single-phase and multi-phase aggregation, and parallel execution.

Tested on Linux ARM64 with assertions enabled and three primary segments. aggregates, gp_aggregates, gp_dqa, aggregate_with_groupingsets, and cbdb_parallel also passed.

Checklist

• Followed contribution guide
• Requested review from cloudberry committers

[Copilot]

Copilot review overview

🟡 Changes recommended

The hash aggregation path still permits incorrect global-group behavior for constant GROUP BY queries.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Hash aggregation mishandles constant GROUP BY clauses · New

What changed in this PR

Fixes incorrect results for constant GROUP BY queries on empty input during multi-phase aggregation.

Changes:

• Adjusts aggregation strategy selection.
• Adds regression coverage across planners and execution modes.
• Updates affected expected outputs and schedules the test.

File	Description
src/​test/​regress/​sql/​gp_group_by_constant.sql	Adds regression queries.
src/​test/​regress/​greenplum_schedule	Schedules the regression test.
src/​test/​regress/​expected/​gp_group_by_constant.out	Adds expected results and plans.
src/​test/​regress/​expected/​bfv_aggregate.out	Updates affected plan output.
src/​backend/​cdb/​cdbgroupingpaths.c	Adjusts aggregation path selection.
contrib/​pax_storage/​src/​test/​regress/​expected/​bfv_aggregate.out	Updates corresponding plan output.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Alena0704]

You should rebase your branch on the current version of main branch.

[Alena0704]

I think you should add at least two more tests with enabled enable_parallel parameter - there are none now:

--the same query with explain (costs off) to check that Finalize GroupAggregate has been chosen
SELECT count(*)
FROM group_by_constant_empty
WHERE n % 2 = 0
GROUP BY n % 2; --extecting 0 rows

--and the same with explain (costs off) to check that TupleSplit has been chosen
SELECT count(DISTINCT n) FILTER (WHERE n < 0),
       count(DISTINCT c0)
FROM group_by_constant_data
GROUP BY 'x'::text; --expecting (0, 1)

[krylosov-aa]

Done

[leborchuk]

LGTM, testset is good

[Alena0704]

The fix looks correct, LGTM either