Parameter · Query Tuning / Planner Method Configuration
enable_partitionwise_aggregate
Enables partitionwise aggregation and grouping.
- Default:
off - Type: bool
- Applies: Session (any user)
In plain words
When you group a partitioned table, PostgreSQL can aggregate each partition on its own and just stack the results, instead of first gluing all partitions together and grouping one huge stream. It is off by default because planning gets more expensive with many partitions.
For DBAs and operators
If the GROUP BY includes the partition key, each partition's groups are complete on their own, so the plan becomes Append → HashAggregate per partition. If not, PostgreSQL can still do partial aggregation per partition followed by a Finalize step. Smaller per-partition hash tables fit in work_mem more easily, and the work can be spread by Parallel Append.
Measured on 18.6 with four partitions, SELECT d, count(*) FROM m GROUP BY d (no parallelism): default plan HashAggregate over Append, cost 10,169; with enable_partitionwise_aggregate = on: Append of four HashAggregates, cost 8,170.
It is off by default because the planner must build and cost paths for every partition, which increases planning time and memory for tables with hundreds of partitions. Turn it on per session or per role for analytic workloads on partitioned tables. When off, these paths are simply never generated (no Disabled: true marker).
How to change it
Any user can change it for their session with SET.
See it in context
Related parameters
enable_partitionwise_join enable_partition_pruning enable_parallel_append work_mem