Indexes that earn their keep
The B-tree, and why column order matters
Postgres's default index type is a B-tree โ a sorted, balanced tree that lets it jump to a matching value in roughly logarithmic time instead of scanning every row. Reach for one whenever a column shows up often in a WHERE, a JOIN, or an ORDER BY on a table big enough that a seq scan hurts.
A composite index covers more than one column, and column order is not cosmetic โ it follows the leftmost-prefix rule. An index on (walker_id, status) can serve a query that filters on walker_id alone, or on walker_id AND status together, because both start by narrowing on the leftmost column first. It can NOT efficiently serve a query that filters on status alone โ that's like using a phone book sorted by last name to look someone up by first name only. Rule of thumb: put the column used for equality (walker_id = 42) before the column used for a range or sort (status, created_at).