Re: single table - fighting a seq scan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Radoslav Nedyalkov <rnedyalkov(at)gmail(dot)com>
Cc: Michael Lewis <mlewis(at)entrata(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: single table - fighting a seq scan
Date: 2020-07-14 22:06:04
Message-ID: 2980741.1594764364@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2020-07-14 22:55:25 Re: some random() clarification needed
Previous Message Tom Lane 2020-07-14 21:51:38 Re: Issue executing query from container