Re: 9.5 release notes

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..


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.

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.


With regard to the point about the number of buffer mappings: This has
forced peoples sites down. People have found this out themselves and
patched postgres. That's an entirely different league.

> 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.

Andres