Seq scan pressure review
Scan audit
Postgres sequential scan audit
PostgresAudit reviews sequential scan pressure without assuming every seq scan is bad. The report separates expected scans from costly patterns that deserve EXPLAIN and index review.
Table size context
Index coverage comparison
No automatic index creation
Seq scans need context
A sequential scan on a small table may be fine. A repeated sequential scan on a large, latency-sensitive table can become an index or query review candidate.
Pressure signals
PostgresAudit compares seq_scan counts, rows read, table size, index usage, dead-row pressure, and slow query evidence before escalating a scan pattern.
Index review path
When a scan-heavy table matches repeated filters or joins, the audit links the finding to missing index review instead of claiming an automatic fix.
Plan validation
EXPLAIN remains the gate before action. The same query can choose different plans as row counts, parameters, statistics, and cache state change.
Related topics
RelatedLinks for neighboring audit problems
Use these focused guides to compare query pressure, index decisions, and maintenance signals before you change production.
FAQ
Frequently asked questions
These answers stay inside the current PostgresAudit product boundary: read-only collection, evidence-gated findings, and human-reviewed next steps.
Are sequential scans always bad in Postgres?
No. PostgreSQL often chooses a sequential scan correctly when the table is small or the predicate is not selective enough for an index to help.
What makes a sequential scan worth investigating?
Large table size, repeated scan frequency, high rows read, slow query correlation, and poor index coverage make a sequential scan worth deeper review.
Can PostgresAudit tell me which index to create?
It can surface missing index candidates and the evidence behind them, but it does not automatically create indexes or bypass EXPLAIN validation.
Does this replace query plan analysis?
No. It narrows the list of scan-heavy areas to inspect. Query plan analysis is still required before changing SQL or indexes.