Radoslav Nedyalkov writes:
> 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
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
Radoslav Nedyalkov 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. Howev
Ah, I could have messed up the examples I gave. Row numbers are different.
Once again the plans , sorry about that.
-- 200 entries
Gather (cost=1000.00..106905910.97 rows=7893 width=8)
Workers Planned: 2
-> Parallel Seq Scan on te (cost=0.00..106904121.67 rows=3289 width=8)
Fil
rows=3832
rows=3870
Your estimate changed very little when you included 100 values vs 200
values. That is interesting to me.
What does the below query give you? How many of those 200 values are found
in the MCVs list? If n_distinct is low, and most of the values are NOT in
the most common value l
Hi Forum,
I'm scratching my head around the following case:
*te* is a 80M rows, 100GB table. It is a bare simple select over indexed
attribute of it.
EXPLAIN SELECT te.id FROM te WHERE te.current_pid IN (240900026,
240900027,
240900028,
-- 200 entries ...
Gather (cost=1000.00..61517367.85 r
