select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / QUERY TUNING

min_eager_agg_group_size

Read PG 20 devel manual ↗

Sets the minimum average group size required to consider applying eager aggregation.

Development snapshot. These definitions may change before release.

Type
real
Context
See manual
Measured default
No measurement for this version
Unit

Definition PG 20 devel manual

Sets the minimum average group size required to consider applying eager aggregation. This helps avoid the overhead of eager aggregation when it does not offer significant row count reduction. The default is 8.

Measured default history
Version intervalDefault
19 – 198
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

How it works

PostgreSQL describes min_eager_agg_group_size as follows: “Sets the minimum average group size required to consider applying eager aggregation.” It can be changed per session, which makes plan or behavior comparisons possible without changing every workload. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster's effective setting.

This cost threshold represents the estimated average input rows per group needed before eager aggregation is considered worthwhile. A higher value demands more row reduction; a lower value explores more eager-aggregation paths but can spend planning and execution work on groups that barely shrink the join input.

Read it together with enable_eager_aggregate, enable_hashagg, enable_partitionwise_aggregate, work_mem. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Operational considerations

Treating the measured boot_val for min_eager_agg_group_size as proof of the effective value on an initialized or managed cluster.

Applying a change as though it were immediate while pg_settings reports user context.

Changing this setting in isolation without checking the linked limits, observability, and rollback path.

Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Workload guidance

OLAP: Test joins with meaningful pre-aggregation opportunities, stale and fresh statistics, and spill pressure. Compare total CPU, peak memory, intermediate rows, and parallel plans, not just one query's elapsed time.

OLTP: Use a session-level experiment with EXPLAIN (ANALYZE, BUFFERS) and a representative parameter distribution. Keep the default unless eager aggregation consistently reduces rows and latency without plan instability.

SMALL: Leave planner switches and thresholds at their defaults until a repeatable regression is isolated. Fix cardinality statistics first; forcing a path globally can trade one improvement for many regressions.

Version history 1
  1. PG 18 → 19added

Related entries

Further reading

Definition snapshot: english-manuals:afbb6ed1eabf1edaf2cc2093ad0… · English manual source