On 03/05/2013 12:33 AM, Robert Haas wrote: > 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. It also weakens our argument (per versioning policy) that patch releases are *totally safe* and are something you can apply without extensive testing and QA per http://www.postgresql.org/support/versioning/ .
I have enough trouble getting people to update as it is. I'd be interested in being able to turn on fixes/enhancements, but having behaviour changes that aren't clear wins in all cases turned on by default seems likely to weaken trust from users who're already way too leery of updating. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
