trace_sort

Definition PG 18 manual

If on, emit information about resource usage during sort operations.

How it works

trace_sort emits internal resource-use messages for sort operations, including memory, run generation, merge passes, and timing details useful to PostgreSQL developers.

It is diagnostic logging, not the same as EXPLAIN's Sort Method output or log_temp_files. Enabling it can produce many messages on sort-heavy workloads.

The switch does not alter work_mem, the sorting algorithm, or spill thresholds. It should be scoped to a reproduction and paired with log-level settings that actually capture the output. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Operational considerations

Leaving trace_sort enabled after the bounded diagnostic or recovery task.

Running the experiment on the only copy of production data.

Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.

Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Workload guidance

OLAP: Long analytical runs can amplify trace_sort's debug overhead and artifacts. Prefer standard EXPLAIN and statistics first, and isolate any developer experiment from normal users.

OLTP: Do not tune production OLTP with trace_sort. Enable it only for a bounded reproduction with an owner, log/disk budget, rollback condition, and evidence-capture plan; restore the default immediately afterward.

SMALL: Keep trace_sort at its upstream default. A small host has less spare CPU, disk, connection, and log capacity for developer instrumentation.