Adding an index made it slower, and that was correct

The report page had gone from fast to unusable as the table crossed a few million rows. The obvious index existed. The planner ignored it and chose a sequential scan, and adding a second, more specific index made the whole thing measurably worse.

The table had a status column with four values, and ninety-four percent of rows were in one of them. Every query filtered on exactly that value. An index on a column where almost every row matches is not selective — reading it and then fetching those rows individually is more work than reading the table straight through. The planner was not confused. It was correct, and my index was decoration.

What actually fixed it was changing the question. The reports only ever looked at the last ninety days, so the useful index was on the timestamp, with the status as a condition on a partial index rather than a leading column. Ninety-second report, then two hundred milliseconds.

The habit worth building: read the plan before you write the index. Cardinality and the shape of the query decide what helps, and no amount of adding indexes substitutes for looking. Indexes also cost you on every write, which is a bill that arrives later and quieter.