Postgres temp writes check for spill-heavy queries
PostgresAudit surfaces PostgreSQL temp write pressure from read-only statistics so teams can identify queries likely spilling to disk before changing work_mem or indexes.
What temp writes usually mean
Temp writes often appear when sorts, hashes, materialization, or large intermediate results spill beyond memory. The audit ranks candidates by observed temp-block pressure and query cost.
Why workload context matters
A batch report that spills once a day is different from an endpoint that spills thousands of times. PostgresAudit compares temp writes with total time, calls, rows, and read pressure.
Safer diagnosis before tuning
The report points to EXPLAIN (ANALYZE, BUFFERS), query shape review, index review, and controlled work_mem testing instead of recommending broad production memory changes.
Read-only boundary
PostgresAudit does not monitor in real time, change work_mem, or rewrite queries automatically. It provides evidence-gated findings for engineers to verify.
RelatedLinks for neighboring audit problems
Use these focused guides to compare query pressure, index decisions, and maintenance signals before you change production.
Frequently asked questions
These answers stay inside the current PostgresAudit product boundary: read-only collection, evidence-gated findings, and human-reviewed next steps.
Does every temp write indicate a problem?
No. Some analytical or maintenance queries can write temp data acceptably. The risk rises when temp writes are frequent, user-facing, or tied to high total runtime.
Can PostgresAudit change work_mem automatically?
No. It only reports evidence. Memory tuning needs workload review because a global increase can raise concurrency risk and make incidents worse.
What evidence should be checked after a temp write finding?
Use EXPLAIN (ANALYZE, BUFFERS), inspect sort and hash nodes, compare rows estimated versus rows returned, and review whether an index or query rewrite reduces the spill.
Do temp writes always come from missing indexes?
No. Missing indexes can contribute, but temp writes can also come from joins, aggregation, sorting, CTE shape, bad estimates, or large result sets.