min_eager_agg_group_size

min_eager_agg_group_size — Sets the minimum average group size required to consider applying eager aggregation. Observed in PG19 Beta 3; its last measured boot default is 8 in PG19 Beta 3, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Sets the minimum average group size required to consider applying eager aggregation.”

Identity

Type , Valuereal: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value—: Raw unit
Range , Value0 – 1.79769e+308: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueQuery Tuning / Planner Cost Constants: Upstream classification
Latest boot value , Value8: 8

Lifecycle

Fact	Value
First observed	PG19 Beta 3
Present in	PG19 Beta 3
Removed in	No
Introduction commit	`8e11859102f9` — Implement Eager Aggregation
Commit date	2025-10-08
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG19 Beta 3	`8`	—	8

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.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
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.
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.
Small nodes	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.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG19 Beta 3 unmodified; OLAP: PG19 Beta 3 unmodified; CRIT: PG19 Beta 3 unmodified; TINY: PG19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

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.

enable_eager_aggregate · enable_hashagg · enable_partitionwise_aggregate · work_mem · hash_mem_multiplier