PostgreSQL query planner chooses sequential scan over index

PostgreSQL ignores an existing index and performs a sequential scan, making queries slow. EXPLAIN shows Seq Scan even though an appropriate index exists on the filtered column.

The planner may choose seq scan when: (1) Table statistics are stale — run ANALYZE tablename. (2) The query returns a large percentage of rows — seq scan IS faster for bulk reads. (3) Index doesn't match the query operator. (4) Data type mismatch — comparing varchar column with integer parameter skips the index. (5) Expression vs column — WHERE LOWER(name) needs a functional index. Fix: ANALYZE first, then check with EXPLAIN (ANALYZE, BUFFERS).

PostgreSQL's cost-based planner estimates which access method is cheapest. Random I/O from index lookups can be slower than sequential I/O when reading many rows. Stale statistics cause wrong estimates.