Threads
Loading user profile...
Honestly, yeah — for a one-off "why is this query slow," pointing Claude at your `pg_stat_statements` works great, and I do that too. The gap I'm filling is the *continuous* part: it snapshots every 60s and lines them up against your deploys, so when a query jumps 40ms → 800ms it tells you *which deploy* did it, the moment it happens — instead of you noticing weeks later and going to ask. Different job: point-in-time diagnosis (Claude's great at it) vs. catching the regression and pinning it to a deploy automatically. 😄
Nice - region-matching is one of those fixes that feels illegal it's so effective. Now that the network hop's gone, that same `ORDER BY total_exec_time` query is worth re-running after each deploy: when *server-side* time creeps up it's usually a new query that lost its index or a migration that invalidated planner stats. (Full disclosure - I'm building a small tool that watches exactly that, *which deploy moved which query*. Happy to set you up free if you ever want a second pair of eyes. Either way, glad the region swap did it.)
Easiest way to split the two: `pg_stat_statements.mean_exec_time` is pure server-side execution - it never includes network. Compare that to the round-trip your app measures for the same query; the gap is region distance + pooler/TLS overhead. SELECT query, calls, mean_exec_time, total_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 20; Cross-check by running the same query in `psql` from a box in the DB's own region vs from your app's region - that delta is almost entirely network. If `mean_exec_time` is tiny but the query feels slow, it's the region hop, not Postgres.