On Thu, Feb 28, 2013 at 3:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Whichever way we go, the resulting patch is likely to be too large and
> invasive for me to feel terribly comfortable about back-patching it into
> 9.2. AFAICT this issue only arises for indexquals extracted out of
> larger OR conditions, so maybe it's not worth taking such a risk for.
EnterpriseDB has received a number of complaints from our customers
resulting from planner behavior changes which were back-patched; so I
am not sanguine about back-patching unless the situation is pretty
darn dire and the fix is pretty darn near certain to be an improvement
in every case. As we have discussed many times here and on
pgsql-performance, DBAs seem to prefer a query plan that's the same
every time, even if it's bad. Updating to get a security fix and
having plans change under you proves to be an unpleasant surprise.
> A downside of this approach is that to preserve
> the same-number-of-rows assumption, we'd end up having to enforce the
> extracted clauses as filter clauses in parameterized paths, even if
> they'd not proved to be of any use as index quals.
I'm not sure I fully grasp why this is a downside. Explain further?
Since there's little point in using a paramaterized path in the first
place unless it enables you to drastically reduce the number of rows
being processed, I would anticipate that maybe the consequences aren't
too bad, but I'm not sure.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
