Two of 311 performance advisories have a real mechanism. event_log (265k rows)
has no index containing company_id, so a company-scoped read falls back to a
primary-key scan with a filter. And journal_entries has 37 inbound foreign keys
with roughly 16 children lacking a usable index, so every deleted entry fires a
sequential scan per child: stripe_payouts has 0 rows and 77 445 seq scans,
supplier_invoices 2 153 rows and 725 816.
This is index hygiene, not a user-facing bug. In the measured 24 hours there
were zero 5xx across 250 838 gateway requests at p95 63 ms, and GET /api/events
had no traffic at all.
Roughly 14 indexes, not 173. Child tables under about 500 rows are skipped: a
one-page sequential scan beats an index probe and the planner ignores the index
anyway. Every candidate was checked against prod first, and any already covered
by an existing index whose partial predicate is implied was dropped, so this
adds no duplicate.
Claude-Session: https://claude.ai/code/session_016ifKg6Ec67A39oxfGPU1yc
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Jakob Wennberg
237bdd0366