I've looked into this:
http://archives.postgresql.org/pgsql-bugs/2012-04/msg00058.php
and concluded that it's not very practical to fix it properly
right now. A real fix will involve rearranging things so that
construction of the filter-condition list happens at Path creation
time, not createplan time, and that's a rather invasive change.
So I want to put it off until 9.3.
However, I did think of a simple one-line hack we could apply to mask
the worst effects of the bogus estimate, which is just to clamp the
correction factor from the indexquals to be not more than the original
cost estimate for the baserestrict quals, at line 461 in HEAD's
costsize.c:
- cpu_per_tuple -= index_qual_cost.per_tuple;
+ cpu_per_tuple -= Min(index_qual_cost.per_tuple,
+ baserel->baserestrictcost.per_tuple);
This seems safe and back-patchable.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
