Owen Nelson <onelson@gmail.com> 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)
(actualtime=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
