Re: single table - fighting a seq scan - Mailing list pgsql-general

From Tom Lane
Subject Re: single table - fighting a seq scan
Date
Msg-id 2980741.1594764364@sss.pgh.pa.us
Whole thread Raw
In response to Re: single table - fighting a seq scan  (Radoslav Nedyalkov <rnedyalkov@gmail.com>)
Responses Re: single table - fighting a seq scan
List pgsql-general
Radoslav Nedyalkov <rnedyalkov@gmail.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



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Issue executing query from container
Next
From: Adrian Klaver
Date:
Subject: Re: some random() clarification needed