Re: Index Scan Backward vs. Sort/Sequential Scan when using ORDER BY

Keith Bussey <kbussey@wisol.com> writes:
> In trying to figure out just why my ORDER BY queries were so slow, I came 
> across something interesting.

The issue here seems to be that Postgres is drastically underestimating
the number of rows that will come out of the indexscan in the second
case:

>               ->  Index Scan using index_client_profiles_gender on 
> client_profiles p  (cost=0.00..35064.98 rows=198 width=8)

198 rows out when you have 54713 females seems a tad low; if it is
indeed much too low, that would explain why the planner mistakenly
prefers this plan.

It'd be interesting to look at the EXPLAIN estimate and actual results for

SELECT count(*) FROM client_profiles p    WHERE (p.profiles_gender='F');

SELECT count(*) FROM client_profiles p    WHERE (p.profiles_gender='F')    AND (p.profiles_orientation[2] = 'F' OR
p.profiles_orientation[1]='M');

I suspect the main problem may be lack of stats about the array element
distributions.  Does profiles_orientation really need to be an array,
or could you break it out into separate fields?
        regards, tom lane