Cap parallel workers that multiply CPU and memory
One parallel query is not one backend. Each worker is a separate process with its own CPU core and its own work_mem grant, so a query that looks fine alone becomes a core-and-RAM multiplier the moment concurrency arrives.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
Parallel query is a throughput feature that silently changes the arithmetic of capacity. The planner decides how many workers to launch per Gather node without any awareness of how many other sessions are doing the same thing, so cores and memory are committed per query and only bounded cluster-wide by limits most people never tune.
Meridian's analytics query plans with several workers and finishes comfortably in isolation. During a peak hour a dashboard fires it repeatedly. Each execution claims its leader plus its workers, every one of them a process on a core with its own memory budget, and the transactional workload is left competing for what remains.
In plain English
When PostgreSQL runs a query in parallel it does not split one process across cores — it starts extra processes, called workers, and each one is a full backend. That matters twice over. Each worker occupies a core, so one query can hold several at once. And each worker gets its own copy of the per-operation memory budget, so the memory a query can claim scales with the number of workers too. On a quiet system that is exactly what you want, and it is why the query is fast. The trap is that nothing in the plan accounts for the other sessions doing the same thing at the same moment: multiply workers by concurrent queries and you can commit far more cores and memory than the machine actually owns.
Full runbook for this incident
- The full identify checklist — the exact signals that tell you it's this incident
- Every diagnostic query; PostgreSQL 18 output is attached only to the steps we captured
- The resolution path and the pitfalls that make it worse
- Mitigation steps to stop it recurring, plus a verify-you're-done query
More in this category
Other Query performance runbooks
Neighbouring incidents that share the same diagnostic surface.
Connected
How this connects to the rest of the library
A live view of this page's real cross-references — what explains it, what fixes it, what to tune, and where to go next. Every link is an authored relationship, not a guess.
Fixes these errors