Missing index candidates
Index audit
Postgres missing index check
PostgresAudit flags missing index candidates only when query and table evidence support review. It does not create indexes automatically or treat AI guesses as production advice.
Sequential scan pressure
Slow query correlation
Human-reviewed index decisions
Candidate, not command
A missing index finding is a review candidate. The audit looks for scan-heavy access, repeated slow statements, filter patterns, and table size before suggesting next diagnostics.
Signals used for review
Useful evidence includes seq_scan pressure, idx_scan balance, relation size, estimated row counts, pg_stat_statements cost, and whether the query shape has a stable predicate.
Composite index caution
Composite indexes can help repeated filters and joins, but column order, selectivity, writes, and existing indexes must be checked before production rollout.
EXPLAIN gate
PostgresAudit asks for EXPLAIN validation before an index is treated as safe. Plan changes should be compared against workload risk, not only one query snapshot.
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.
Will PostgresAudit create missing indexes?
No. It is read-only. It can identify candidates and explain the evidence, but index creation remains a human production change.
Can every sequential scan be fixed with an index?
No. Sequential scans can be correct for small tables, low selectivity predicates, or queries that read most rows. The audit treats them as signals, not automatic defects.
Does the report include exact CREATE INDEX commands?
It may describe candidate direction and diagnostic requirements, but it does not present unsupported automatic DDL as a finished production fix.
What makes a missing index candidate stronger?
Repeated slow queries, large scan-heavy tables, stable predicates, poor existing index coverage, and EXPLAIN evidence make a candidate stronger.