Owen Nelson <onelson@xxxxxxxxx> writes: > The hope is the sub-select would leverage the index > "message_payload_not_null_pidx" but when I `EXPLAIN ANALYZE` the query, I > see a seq scan instead. I think your problem is the horrid rowcount misestimation here: > -> Seq Scan on message message_1 (cost=0.00..2050554.24 rows=6175068 width=38) (actual time=8424.977..20880.945 rows=65 loops=1) > Filter: ((payload IS NOT NULL) AND (expiration <= now())) > Rows Removed by Filter: 37772897 The planner seems to think that about a sixth of the table satisfies the filter condition, which is way more than enough to discourage it from using an indexscan. If it had gotten an estimate within even one or two orders of magnitude of the reality of 65 rows, it'd have gone for an indexscan, I'm pretty sure. Are your ANALYZE stats up to date on this table? If so, there must be some strong correlation between the payload and expiration conditions that the planner doesn't know about. Perhaps creating extended statistics on those two columns would help. regards, tom lane
