On Fri, Aug 7, 2015 at 12:02 PM, Andres Freund <andres@anarazel.de> wrote:
> 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 put. I don't see much of a downside to having smaller performance
improvements listed, provided they're towards the end of the
performance section.
It is true that many users don't really care much about performance
stuff, but among those that give the release notes any more than a
cursory look, I bet most care a lot. It's not as if the release notes
are the only way, or even the best way of learning about new features
for those with a more casual interest. Keeping the features list short
and sweet is more of a job for advocacy people that prepare press
releases and so on.
>> 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.
I strongly agree.
--
Peter Geoghegan