Re: About bug #6579

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: About bug #6579
Date: 2012-04-11 23:34:49
Message-ID: 15089.1334187289@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
index-qpqual-costing.patch text/x-patch 3.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-04-12 00:38:08 Re: pg_upgrade improvements
Previous Message Tom Lane 2012-04-11 21:44:32 About bug #6579