Tag: sql performance

Alexander Belanger's guide is useful because it connects ordinary application decisions to the database behaviors they eventually expose: schemas, query shape, index ordering, connection pressure, autovacuum, long-running writes, and lock-aware queue work. It is practical without pretending that every slow query needs an index, and the EXPLAIN (ANALYZE, BUFFERS) habit is exactly the one to cultivate before improvising a fix.

The Hacker News thread supplies an important amendment to the word "survival": a production database also needs proven backups, restore drills, and clear recovery ownership. Tuning plans and avoiding bloat keep the service healthy; they do not recover a lost or corrupt system. The best reading of this guide is as a strong operating playbook that sits beside, not ahead of, a tested recovery plan.

This is a good practical explainer because it connects the usual "add an index" advice to the physical model underneath: pages, tuples, ctid, B-tree roots and leaves, and the way PostgreSQL can avoid dragging a query through the whole table.

The Hacker News thread gets the teaching problem right. This is exactly the kind of PostgreSQL-specific reference you want when someone knows queries are slow but does not yet have a mental model for why missing indexes hurt. The deeper lesson is that performance work gets easier when the database stops being a black box and starts looking like a set of page-level tradeoffs.