work_mem
Sets per-operation memory for sorts, hashes, and similar executor nodes, so one query can consume it many times over.
Defaults and ranges on this page were read from pg_settings on live PostgreSQL 18.4.
What this means
work_mem is the memory budget for one step of one query, a sort, or the hash table built for a join. The trap is the word 'per': a single query can run several sorts and hashes at once, and every connection runs its own, so the real memory used is work_mem multiplied out many times, not just once. Set it too low and those steps spill to disk and slow down; set it too high and a burst of traffic can each grab multiple slots and exhaust RAM. That is why 4 MB is a per-operation budget you raise carefully, usually for a single query rather than the whole server.
When it matters
Tune when sorts and hashes spill to disk, but model concurrency before changing it globally.
| Default | 4 MB |
|---|---|
| Range | 64 – 2147483647 |
| Category | Executor memory |
SHOW work_mem;Tradeoffs
- • Too low: more disk spills during sorts and hash operations.
- • Too high: runaway memory consumption when many concurrent queries each allocate multiple work_mem slots.
- • Per-session overrides are often safer than globally increasing the setting.
Workload profiles
Reporting queries
Raise selectively for large hash joins and sorts.
Use SET LOCAL or role-specific settings where possible.
High-concurrency APIs
Keep defaults modest and tune only targeted workloads.
Concurrency math matters more than a single fast query benchmark.