Why this problem matters
work_mem may be consumed per plan operation, such as a sort or hash, rather than once per connection. Many concurrent operations can turn an apparently reasonable value into aggregate memory risk.
How to diagnose it
Review the current setting together with temporary-file bytes and query concurrency. temp_bytes is cumulative and cannot identify the spilling statement by itself.
The query only reads the current work_mem value and database-level temporary-file counters. Comparing deltas between samples is more meaningful.
SHOW work_mem;
SELECT datname, temp_files, temp_bytes, stats_reset
FROM pg_stat_database
ORDER BY temp_bytes DESC NULLS LAST;A safe solution approach
Do not raise the global value based on one slow query alone. Test query plans, concurrency, and any safe session- or transaction-level requirement under controlled conditions.
Why continuous monitoring matters
moon helps correlate temporary-file growth with activity trends at low overhead. Slack, PagerDuty, and webhook routing keeps persistent pressure visible.
Frequently asked questions
Does increasing work_mem accelerate every sort?
No, some plans may remain unchanged while aggregate memory use rises substantially. Validate the decision with real plans and production-like concurrency.
How does moon help with this problem?
moon continuously observes SQL Server, PostgreSQL, and MongoDB signals, helping teams evaluate the problem as a trend instead of relying on a one-time check.