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

Keith Bussey <kbussey(at)wisol(dot)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