enable_eager_aggregate

Definition PG 20 devel manual

Enables or disables the query planner's ability to partially push aggregation past a join, and finalize it once all the relations are joined. The default is on.

How it works

PostgreSQL describes enable_eager_aggregate as follows: “Enables 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.

Eager aggregation partially pushes aggregation below a join so fewer rows may cross the join, then finalizes the result after all relations are joined. It is considered only when estimated average group size reaches min_eager_agg_group_size; estimates, grouping semantics, memory, and alternative join paths still determine whether the planner selects it.

Read it together with min_eager_agg_group_size, 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 enable_eager_aggregate 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.