Group
Appears in EXPLAIN asGroup
Collapses adjacent equal rows in sorted input (GROUP BY without aggregates).
What it is
A Group node deduplicates groups from already-sorted input when there are grouping columns but no aggregate functions to compute. It's a lightweight cousin of GroupAggregate.
When the planner picks it
Rarely on its own in modern PostgreSQL; mostly when grouping sorted input without aggregates.
Is it good or bad?
Cheap when its input is already sorted. If a Sort feeds it just to enable grouping, a HashAggregate might be cheaper.
In depth
Lightweight grouping
A Group node deduplicates adjacent rows from sorted input — collapsing
runs of equal grouping columns into one output row per group. There are no
aggregate functions; it's just "give me one of each."
It's the leanest grouping node and only appears when both conditions hold:
- the query has
GROUP BYcolumns but no aggregate functions; - the input is already sorted on the grouping columns (typically from an index scan or an earlier Sort).
If those don't hold, the planner uses GroupAggregate (sorted, with aggs) or
HashAggregate (hashed) instead.
When it's the right choice
The classic case is "give me distinct combinations from an indexed prefix":
SELECT customer_id, status
FROM orders
GROUP BY customer_id, status;
If there's an index on (customer_id, status), the planner can stream the
index in order, push it through Group, and emit distinct combos with near-
zero memory.
If you see a big Sort feeding a Group only to deduplicate, a HashAggregate is often cheaper — much like the DISTINCT story.