enable_distinct_reordering

enable_distinct_reordering — Enables reordering of DISTINCT keys. Observed in PG18–19 Beta 3; its last measured boot default is on 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: “Enables reordering of DISTINCT keys.”

Identity

Type , Valuebool: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueQuery Tuning / Planner Method Configuration: Upstream classification
Latest boot value , Valueon: on

Lifecycle

Fact	Value
First observed	PG18
Present in	PG18–19 Beta 3
Removed in	No
Introduction commit	`a8ccf4e93a7e` — Reordering DISTINCT keys to match input path’s pathkeys
Commit date	2024-11-26
Discussion	thread 1

Default history

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

How it works

enable_distinct_reordering controls whether the planner may choose reordering DISTINCT keys to match useful input pathkeys and avoid or reduce sorting.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

Tip

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

Workload	Guidance
OLTP	Keep the PG18 default on. For a suspected regression, compare session-local plans and verify whether reordered DISTINCT keys actually match useful input pathkeys or merely trade one sort for another.
OLAP	Large DISTINCT operations can benefit when reordering exploits index, merge, or existing sort order. Measure sort memory, spill volume, planning time, and total execution rather than disabling the optimization globally after one plan.
Small nodes	Keep on unless a reproducible plan regression is demonstrated. If sorts spill, correct work_mem and plan inputs before treating this planner switch as a permanent hint.

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: PG18–19 Beta 3 unmodified; OLAP: PG18–19 Beta 3 unmodified; CRIT: PG18–19 Beta 3 unmodified; TINY: PG18–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Treating enable_distinct_reordering as a query hint even though it affects every plan built in its scope.
Testing an already cached prepared plan and concluding that the setting has no effect.
Masking stale statistics or cardinality errors by disabling a plan method globally.
The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

enable_sort · enable_incremental_sort · enable_presorted_aggregate · work_mem