Re: 9.5 release notes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: 9.5 release notes
Date
Msg-id 20150807184311.GA4965@momjian.us
Whole thread Raw
In response to Re: 9.5 release notes  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: 9.5 release notes  (Andres Freund <andres@anarazel.de>)
Re: 9.5 release notes  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
List pgsql-hackers
On Fri, Aug  7, 2015 at 11:53:30AM -0400, Robert Haas wrote:
> On Thu, Aug 6, 2015 at 10:24 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >> * 2014-10-02 [3acc10c9] Robert..: Increase the number of buffer mapping partition..
> >>   should we mention this? This has been patched by a number of
> >>   downstream vendors and users, so it's probably worth calling out?
> >
> > Uh, I am not sure why general users would care.
> 
> Because it significantly improves performance on workloads that don't
> fit into shared_buffers and have concurrency.
> 
> >> * 2014-07-14 [91f03ba] Noah M..: MSVC: Recognize PGFILEDESC in contrib and conv..
> >>   2015-04-16 [22d0053] Alvaro..: MSVC: install src/test/modules together with c..
> >>   Don't seem to warrant a release note entry.
> >
> > User-visible changes.
> 
> It seems really strange to me to say that things which improve
> performance or change query plans are somehow not user-visible, but
> applying a file description to Windows binaries is user-visible.  I am
> willing to bet you a beverage of your choice that a lot more people
> are going to notice the performance improvements and planner changes
> than will ever notice that stuff.

Well, we could just throw a "Postgres 9.5 is faster" release note item
in there and call it a day.  ;-)  Of course, there are certain
performance items we have to list:  user-visible changes, e.g. new
features (BRIN), and faster behavior for common operations, i.e. things
that will cause users to try things that were too slow in the past.

On the opposite end, we have many changes that shave 1% off of query
execution time with no change in user behavior, which we probably don't
want to list.

So, the line is between those somewhere, and the question is where is
that line?  If two people think this item is above that line, then let's
add it.  If you can provide text, I can add it.  If you have others, we
can add those too.

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.

> (I realize now that compiling the release notes must be a somewhat
> thankless task, so let me just say that I do appreciate the work
> you've put into this very much and the comments above shouldn't be
> understood to take anything away from that.  The fact that we don't
> agree on what the criteria ought to be does not mean that I don't
> appreciate you doing the work.)

Considering the number of almost-arbitrary decisions I have to make to
write the major release notes, I am surprised at how few complaints I
get.  Of course, I have been clearly told by core that no one else wants
this job.

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Raising our compiler requirements for 9.6
Next
From: Heikki Linnakangas
Date:
Subject: Re: WIP: SCRAM authentication