Thread

1. About bug #6579

   Tom Lane <tgl@sss.pgh.pa.us> — 2012-04-11T21:44:32Z

   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
   
   

2. Re: About bug #6579

   Tom Lane <tgl@sss.pgh.pa.us> — 2012-04-11T23:34:49Z

   I wrote:
   > 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.
   
   ... and on still further review, I've concluded that this isn't that
   expensive to fix locally after all, at least in HEAD; and we get the
   further benefit of saner costing of join cases.  (As per attached.
   Basically it'll cost us one list_difference_ptr operation per IndexPath,
   on what will typically be pretty short lists.  The cost_qual_eval
   operation should be negligible either way, because it will be hitting
   RestrictInfo nodes with already-cached costs.)
   
   I'm still inclined to put the quick Min() hack into older branches,
   though.  While this larger fix could possibly be back-patched, it might
   change cost estimates by enough to destabilize plan choices.  Given
   the small number of complaints about the issue to date, it doesn't seem
   worth taking any risk for in released branches.
   
   			regards, tom lane