"Nick Fankhauser" <nickf@ontko.com> writes:
> This indicates to me that 1 isn't too shabby as an estimate if the whole
> name is specified, but I'm not sure how this gets altered in the case of a
> "LIKE"
For a pattern like "SANDERS%", the estimate is basically a range estimate
for this condition:
> ((actor_full_name_uppercase >= 'SANDERS'::character varying) AND
> (actor_full_name_uppercase < 'SANDERT'::character varying))
> n_distinct | -0.14701
> Question: What does it mean when n_distinct is negative?
It means that the number of distinct values is estimated as a fraction
of the table size, rather than an absolute number. In this case 14.7%
of the table size, which is a bit off compared to the correct value
of 43% (1453371/3386359), but at least it's of the right order of
magnitude now ...
> -> Index Scan using
> actor_full_name_uppercase on actor (cost=0.00..456.88 rows=113 width=42)
> (actual time=32.80..3197.28 rows=3501 loops=1)
Hmm. Better, but not enough better to force a different plan choice.
You might have to resort to brute force, like "set enable_nestloop=false".
Just out of curiosity, what do you get if you do that?
regards, tom lane
