Re: single table - fighting a seq scan

Shame on me. It's a partial index - *where is not null.*
Put the* is not null *predicate in place and planner always goes for index.
(tested with thousands of IN entries)
CTE version always goes for index too even *without **is not null , *which
led to a slight confusion.

Thanks Tom, Michael,
Best
Rado

On Wed, Jul 15, 2020 at 1:06 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Radoslav Nedyalkov <rnedyalkov(at)gmail(dot)com> writes:
> > Ah, I could have messed up the examples I gave. Row numbers are
> different.
> > Once again the plans , sorry about that.
>
> Given that it works at 100 entries and not 101, I can't escape the
> suspicion that you're being burnt by predtest.c's MAX_SAOP_ARRAY_SIZE
> limit. However, that only affects the planner's willingness to make
> constraint proofs involving the large IN clause, and nothing you've
> mentioned here explains why such a proof would be needed. Is there
> something you're not telling us about this table's schema? (I'm
> wondering if the index is partial, for instance, though one would
> think that the CTE form of the query wouldn't work either if so.)
>
> regards, tom lane
>