replacement_sort_tuples

replacement_sort_tuples — Sets the maximum number of tuples to be sorted using replacement selection. Observed in PG9.6–10; its last measured boot default is 150000 in PG10, with user context. It was removed in PG11.

Note

Fact — official short description: “Sets the maximum number of tuples to be sorted using replacement selection.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value—: Raw unit
Range , Value0 – 2147483647: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueResource Usage / Memory: Upstream classification
Latest boot value , Value150000: 150000

Lifecycle

Fact	Value
First observed	PG9.6
Present in	PG9.6–10
Removed in	PG11
Introduction commit	`0711803775a3` — Use quicksort, not replacement selection, for external sorting.
Commit date	2016-04-08
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.6–10	`150000`	—	150000

How it works

In PG10, replacement_sort_tuples selected when an in-memory sort used replacement selection to produce a long initial run for external merge sorting. It was removed in PG11 with the old replacement-selection path.

The value counted tuples, not bytes, so its memory implications depended on row width and work_mem. It was an algorithm threshold rather than a general sort-memory ceiling.

Modern PostgreSQL does not recognize the parameter. Migration should delete it and tune current sort behavior through work_mem, plan shape, and measured temporary-file use instead. 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	Do not tune replacement_sort_tuples on current PostgreSQL: remove it from upgrade targets and use the current replacement behavior described above. Retain it only when reproducing the historical version.
OLAP	Do not carry replacement_sort_tuples into a modern analytical cluster. Benchmark the supported current mechanisms instead of trying to emulate a removed implementation detail.
Small nodes	Delete replacement_sort_tuples during version migration; an unknown-parameter startup failure is more likely than a benefit. Historical test instances should keep the old upstream default.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG10; 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: PG9.6–10 unmodified; OLAP: PG9.6–10 unmodified; CRIT: PG9.6–10 unmodified; TINY: PG9.6–10 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Changing replacement_sort_tuples without applying its documented unit and configuration context.
Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.
Assuming a configured value guarantees operating-system or storage behavior.
Failing to retest startup, failover, and workload latency after the change.

work_mem · temp_file_limit · enable_sort · trace_sort · log_temp_files