Re: Seeking help with a query that takes too long

"Nick Fankhauser" <nickf(at)ontko(dot)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