pgconfigurator
pgconfigurator

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 BY columns 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.

See also