Sample finding · rule
indexes.missing.v1Missing index candidate on public.events.user_id
Severity: mediumConfidence: 0.85
Problem
Frequent sequential scans on
public.events filter on user_id. The evidence indicates that this access pattern is worth an operator's review.Why it matters
This query is on the hot read path and runs frequently. Current execution wastes shared-buffer cache on rows that the predicate then discards. The gap widens as
public.events grows; addressing it now is cheap and reversible.Evidence
queryid= 0xab12cd34calls= 1,247,392 over 24 hoursmean_exec_time_ms= 11.7- Source refs:
indexes.missing.v1,table=events,column=user_id
Recommended action
Create a single-column index on user_id. Use CONCURRENTLY so the build does not block writes onpublic.events; note that CREATE INDEX CONCURRENTLY cannot run inside a transaction (a common gotcha for migration tools that wrap each statement by default).
CREATE INDEX CONCURRENTLY idx_events_user_id
ON public.events (user_id);
Elevarq
