Negations and Not-Equal Conditions Rarely Earn an Index
An index is good at finding the rows that match; conditions like status <> 'done' or NOT IN (...) describe almost everything, so even a perfect index would have to walk most of it and the planner sensibly chooses a scan instead. The useful move is to flip the condition into the positive list of values you actually want, or to build a partial index over the small side. Recognising this saves you from adding an index that the planner will never pick.
Questions this Concept answers
Why does the planner usually reject the index for `WHERE status <> 'done'` on a table where most rows are not done?
An index only pays off when the condition it serves picks out a small slice of the table. PostgreSQL's partial-index documentation makes that concrete: it shows how to build an index over only the un…