On Thu, Feb 28, 2013 at 3:03 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
