Runbook category
Indexing
Open this category when the question is about the access path itself, which index to add, which type to pick, which column order to use, or which index has been paid for on every write and never read. Come here after a plan has already pointed at a Seq Scan, a Bitmap Heap Scan, or an index that looks right on paper and still loses.
Half of these runbooks add an index: the foreign key you forgot, a covering INCLUDE list, a partial index over the hot subset, a GIN for jsonb containment, a BRIN for a huge append-only table, or the multicolumn order that matches the query. The other half take one away. Unused indexes and redundant duplicates are the cheapest wins most databases still have sitting there. Index-only scans have their own trap: the index can be perfect and still visit the heap until the visibility map catches up.
Query performance is where you read the plan and decide whether an index is the fix at all, including the fillfactor runbook for the case where an index on a hot column is what stopped HOT updates from working. Schema migrations is how you build or validate one without taking ACCESS EXCLUSIVE on a live table. This page is the catalog of shapes, what to build, and what to drop, once you already know the workload.
- Pro
Index the foreign key you forgot
Deleting one parent row scans the whole child table to check the constraint.
- Pro
Make index-only scans actually skip the heap
Plan says Index Only Scan, Heap Fetches is huge, and it is not fast.
- Pro
Covering indexes with INCLUDE
The index finds rows quickly, then the heap trip for the selected columns costs everything.
- Pro
Partial indexes for hot subsets of data
A multi-megabyte index when queries only ever touch last week's rows.
- Pro
Get the multicolumn index column order right
The composite index exists and the planner still sorts, the columns are the wrong way round.
- Pro
GIN indexes for jsonb containment queries
A jsonb @> filter ignores every B-tree you own and reads every document.
- Pro
BRIN indexes for huge append-only tables
A huge B-tree on a timestamp column whose rows already arrive in order.
- Pro
Eliminate redundant and duplicate indexes
Writes are slow and the same leading column is indexed three different ways.
- Pro
Find and drop unused indexes
An index nobody has scanned in years that every INSERT still pays for.