Postgres Slow Query Doctor (EXPLAIN Plan Analyzer)

The problem\n\nA Postgres query is slow, you have run EXPLAIN ANALYZE, and the plan is 80 lines of nested nodes. Which one actually costs the time, and what do you change?\n\n## What it does\n\nGive your agent the plan (EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)) and it ranks the nodes by self time (not the misleading inclusive time) and explains each bottleneck with the exact numbers from your plan:\n\n- Missing index: a sequential scan that reads the whole table and throws most rows away, with the filter and rows removed\n- Memory spills: sorts that went to disk and hash joins split into batches (work_mem)\n- Bad row estimates: reported at the node where the error starts, with the factor and direction (stale stats, correlated columns, CREATE STATISTICS)\n- Nested loops with thousands of inner loops, index-only scans still hitting the heap, lossy bitmaps, JIT overhead\n- Before/after comparison: run the plan again after adding an index and get the speedup plus which findings were resolved, new or persisting\n\n## Safe by design\n\nIt only reads plan files. It never connects to your database, never runs SQL and never creates indexes. The skill tells your agent to ask you to run EXPLAIN ANALYZE yourself, wrapped in a transaction for writes, and not against production without approval. Estimate-only plans (plain EXPLAIN) are accepted and clearly marked UNKNOWN instead of guessing.\n\n## Tested on real plans\n\nTested against plans captured from a real PostgreSQL 16 server: missing index (11.7 ms to 0.13 ms after the index), sort spill, 16-batch hash join, a 133x row misestimate, nested loop with 43,000 inner loops, and estimate-only. 17 tests.\n\n## Requirements\n\nPython 3.8+ standard library only. Linux, macOS or Windows. No network, no packages.\n\n## Limits\n\nAdvice comes from the plan alone: table sizes, existing indexes, write load and server settings are not visible, so suggestions are hypotheses to verify on a non-production copy. One plan is one run; cache state changes timings. Does not read pg_stat_statements or logs.