Keith Bussey <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
