On Mon, Mar 7, 2016 at 3:17 AM, Shulgin, Oleksandr <oleksandr.shul...@zalando.de> wrote: > On Fri, Mar 4, 2016 at 7:27 PM, Robert Haas <robertmh...@gmail.com> wrote: >> >> On Thu, Mar 3, 2016 at 2:48 AM, Shulgin, Oleksandr >> <oleksandr.shul...@zalando.de> wrote: >> > On Wed, Mar 2, 2016 at 7:33 PM, Alvaro Herrera >> > <alvhe...@2ndquadrant.com> >> > wrote: >> >> Shulgin, Oleksandr wrote: >> >> >> >> > Alright. I'm attaching the latest version of this patch split in two >> >> > parts: the first one is NULLs-related bugfix and the second is the >> >> > "improvement" part, which applies on top of the first one. >> >> >> >> So is this null-related bugfix supposed to be backpatched? (I assume >> >> it's not because it's very likely to change existing plans). >> > >> > For the good, because cardinality estimations will be more accurate in >> > these >> > cases, so yes I would expect it to be back-patchable. >> >> -1. I think the cost of changing existing query plans in back >> branches is too high. The people who get a better plan never thank >> us, but the people who (by bad luck) get a worse plan always complain. > > > They might get that different plan when they upgrade to the latest major > version anyway. Is it set somewhere that minor version upgrades should > never affect the planner? I doubt so.
People with meticulous standards are expected to re-validate their application, including plans and performance, before doing major version updates into production. They can continue to use a *fully patched* server from a previous major release while they do that. This is not the case for minor version updates. We do not want to put people in the position where getting a security or corruption-risk update forces them to also accept changes which may destroy the performance of their system. I don't know if it is set out somewhere else, but there are many examples in this list of us declining to back-patch performance bug fixes which might negatively impact some users. The only times we have done it that I can think of are when there is almost no conceivable way it could have a meaningful negative effect, or if the bug was tied in with security or stability bugs that needed to be fixed anyway and couldn't be separated. Cheers, Jeff -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers