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

On Mon, Apr 20, 2026 at 01:30:25PM +1200, David Rowley wrote:
> Maybe there's something committers can put in the commit message to
> make it more obvious which commits matter by referencing some actual
> performance numbers that were published that showed a definitive
> speedup (not just a measurement of noise). I do expect that it's a
> fairly horrible job if we're going to ask Bruce to trawl each thread
> to find what performance numbers were posted. In the past I've tried
> to list some example numbers in commit messages to help Bruce (e.g.
> final paragraph in [2] and [3]). I'm not sure if it does help, or if
> there's something better that could be done instead.

In that thread from PG 17, I said:

https://www.postgresql.org/message-id/ZlKaHOM8HYLy9nCY%40momjian.us

> Well, let's start with a new section for PG 17 that lists these.  Is it
> 20 items, 50, or 150?  I have no idea, but without the user-visible
> filter, I am unable to determine what not-included performance features
> are worthy of the release notes.
> 
> Can someone do that?  There is no reason other committers can't change
> the release notes.  Yes, I realize we are looking for a consistent
> voice, but the new section can probably have its own style, and I can
> make adjustments if desired.
> 
> Also, I think this has gone unaddressed so long because if we skip a
> user-visible change, users complain, but I don't remember anyone
> complaining about skipped performance changes.

So, what is the filter I am supposed to use?  We even have a patch that,
in aggregate, increases performance by 12-17%.  Is that under or over
the threadshold to be included?  I have no idea.  And, even if we agree
on a number, how do I handle commits with no numbers;  this commit
didn't have a number.

Just like with the co-authored-by, I need rules.  I thought I got
agreement on the co-authored-by rules in January 2025 because no one
objected, only to learn recently that many didn't like it, and we
changed the rules, and I used those new rules for PG 19.

I can follow the rules on the wiki:

    https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
    While the major release notes include changes to the documented
    extension interface, it does not include all changes of interest
    to extension developers or Postgres forks because doing so would
    include too many items that would be uninteresting to the general
    audience.  Similarly, performance improvements are not mentioned in
    the release notes unless they are user-visible (e.g., new syntax)
    or significant enough to enable new workloads.

I can't follow rules that require me to consistently identify if a patch
is a performance improvement, and if it is significant enough for the
release notes.  If someone else can do that, please go ahead and stop
blaming me for something I can't do.  I thought if it was easy, someone
else since PG 17 would have either given me rules or done it.

Can committers mention when they want something to be included in the
release notes?  What we can do is to have all the hackers point out the
missing items after I done creating the release notes, as messy as that
is.

One thing we can easily do is to add text to the release notes stating,
"This release includes minor performance improvements that are too
numerous to mention."

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

  Do not let urgent matters crowd out time for investment in the future.