Re: Understanding partial index selection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Owen Nelson <onelson(at)gmail(dot)com>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Understanding partial index selection
Date: 2023-11-28 23:07:57
Message-ID: 186558.1701212877@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Owen Nelson <onelson(at)gmail(dot)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) (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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David Rowley 2023-11-28 23:08:27 Re: Understanding partial index selection
Previous Message Owen Nelson 2023-11-28 22:23:17 Understanding partial index selection