Re: 9.5 release notes - Mailing list pgsql-hackers

On Fri, Aug  7, 2015 at 09:02:09PM +0200, Andres Freund wrote:
> On 2015-08-07 14:43:11 -0400, Bruce Momjian wrote:
> > Well, we could just throw a "Postgres 9.5 is faster" release note item
> > in there and call it a day.  ;-)
> 
> Based on my experience one of the prime reason people move to a new
> version of postgres is performance. And it's not like 'faster!!!' is
> really helpful for them to evaluate the benefits appropriately. A
> scalability improvement isn't going to help somebody concerned with
> single query performance. Somebody concerned about OLTP write
> performance isn't going to be overly excited about the sort performance
> improvements, but somebody doing OLAP style queries very much so.
> 
> The consequence of not listing that is that we're essentially asking our
> users to read through all the changes between two releases. Something
> that takes a long while even for people like you and me who are very
> familiar with the project..

Well, considering I have used the same criteria for years, and I am only
now hearing complaints, I am unsure about the statement that our
existing criteria isn't generally meeting people's needs.

> The *by far* biggest complaint about upgrades with postgres isn't binary
> compatibility (even before pg_upgrade), it's not that there's minor
> incompatibilities (at least not since 8.3, and maybe bytea_output). It's
> that previously working queries don't work anymore. It's always just a
> minority, but they're there. And it's very hard to figure out what's
> up. Is it stats? Different settings? Planner changes? If we then don't
> list changes to the planner, they're screwed.

Well, if we do list them, is that going to help people?  You can say,
"well it might", but we are then in the same logic we use to decide on
adding GUC entries  --- we have to weigh the value of having the entry
vs the overhead of everyone reading the entry.  Now, in this case, it is
a one-time read vs. something that we will keep for years, but the basic
decision process is the same.

And, again, I will say, we are not writing this for ourselves, but for
the general user.

> In comparison to that just about nobody cares about the rest of the
> update but new SQL level stuff and a few other major things? A new field
> in EXPLAIN, debug_assertions read only,  effective_io_concurrency
> settable without effect, VACUUM logs new one more data point, an
> 10+ year old obsolete undocumented option being removed, new icons for
> binaries. They just don't matter.

Well, if we have user-visible behavior, and we don't tell them about it,
they are never going to be able to use it, so it is hard to see how we
could avoid mentioning those.

> > What I _am_ saying is that you should use the same criteria I am using,
> > and just disagree on the place for the line, rather than use a different
> > criteria, which will lead to perpetual complaints.  We can change the
> > criteria, but that is a different discussion.
> 
> We need to change that criteria then.

Then you need to start a new thread on that topic to get community
agreement that I can implement, and we can probably change 9.5 to match.

You might also want to address the fact we don't list all bug fixes in
the release notes either if the bug is a rare, minor event, and/or if
the new error message is sufficient communication to users.

One way of minimizing the downside of any new such entries is to have a
"Minor performance improvements" or "Internal performance improvements"
section in the release notes so people will realize they are not of the
same import as other items --- same for possible new bug fix listings.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +