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
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 |