Re: First draft of PG 17 release notes - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: First draft of PG 17 release notes
Date
Msg-id ZkuZKrjAY_CsykYb@momjian.us
Whole thread Raw
In response to Re: First draft of PG 17 release notes  (Melanie Plageman <melanieplageman@gmail.com>)
List pgsql-hackers
On Mon, May 20, 2024 at 02:35:37PM -0400, Melanie Plageman wrote:
> On Sat, May 18, 2024 at 11:13 AM Bruce Momjian <bruce@momjian.us> wrote:
> > Please see the email I just posted.  There are three goals we have to
> > adjust for:
> >
> > 1.  short release notes so they are readable
> > 2.  giving people credit for performance improvements
> > 3.  showing people Postgres cares about performance
> 
> I agree with all three of these goals. I would even add to 3 "show
> users Postgres is addressing their performance complaints". That in
> particular makes me less excited about having a  "generic performance
> release note item saying performance has been improved in the
> following areas" (from your other email). I think that describing the
> specific performance improvements is required to 1) allow users to
> change expectations and configurations to take advantage of the
> performance enhancements 2) ensure users know that their performance
> concerns are being addressed.

Well, as you can see, doing #2 & #3 works against accomplishing #1.

> > I would like to achieve 2 & 3 without harming #1.  My experience is if I
> > am reading a long document, and I get to a section where I start to
> > wonder, "Why should I care about this?", I start to skim the rest of
> > the document.  I am particularly critical if I start to wonder, "Why
> > does the author _think_ I should care about this?" becasue it feels like
> > the author is writing for him/herself and not the audience.
> 
> I see what you are saying. We don't want to just end up with the whole
> git log in the release notes. However, we know that not all users will
> care about the same features. As someone said somewhere else in this
> thread, presumably hackers spend time on features because some users
> want them.

I think we need as a separate section about performance improvements
that don't affect specific workloads.  Peter Eisentraut created an
Acknowledgements section at the bottom of the release notes, similar to
#2 above, so maybe someone else can add a performance internals section
too.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: libpq compression (part 3)
Next
From: Melanie Plageman
Date:
Subject: Re: First draft of PG 17 release notes