IndexingintermediatePro runbook

Covering indexes with INCLUDE

Add the columns a query returns as INCLUDE payload and the index can answer it without touching the table. A heap-touching bitmap scan over ~100 rows becomes an Index Only Scan with Heap Fetches: 0.

Problem

What you're actually looking at

The symptom as it shows up on a real server.

An ordinary index finds the rows, then PostgreSQL visits the heap to read the columns you selected. If you fold those columns into the index as non-key INCLUDE payload, the scan never has to touch the table at all.

A Meridian query sums payout per courier from courier_ledger. A plain index on courier_id still visits the heap for payout; a covering index carries it in the leaf.

Simple terms

A normal index finds your rows, then PostgreSQL opens the table to read the columns you actually selected. If you tuck those columns into the index itself as INCLUDE payload, the answer is already sitting in the index leaf and the table never has to be touched. The work drops from "find the rows, then go fetch their values" to a single index read.

ProCaptured evidence where the run produced it

Full runbook for this incident

The scenario above is free. What Pro unlocks is the fix: how to identify covering indexes with include, the exact SQL to trace it, PostgreSQL 18 output for the steps we captured, the resolution path, and how to stop it recurring.
  • The full identify checklist, the exact signals that tell you it's this incident
  • Every diagnostic query; lab output is attached only to the steps we actually captured
  • The resolution path and the pitfalls that make it worse
  • Mitigation steps to stop it recurring, plus a verify-you're-done query

Card required. Cancel before day 7 and you are not charged.

Compare plans

ShareLinkedInX

Need the full procedure?

Pro runbooks finish the incident path

Free runbooks teach the shape. Pro opens the full step transcript, edge cases, and prevention depth.

FollowSubstackLinkedInnew errors · lab notes · hiring loops