Horton
Menu

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, David Geier <geidav.pg@gmail.com>, PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-20T09:10:54Z
Lists: 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.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. doc PG 19 relnotes: remove VALIDATE CONSTRAINT lock item

  2. Fix ALTER DOMAIN VALIDATE CONSTRAINT locking

  3. Revert "Enable fast default for domains with non-volatile constraints"

  4. doc PG 19 relnotes: improve awkward or confusing wording

  5. doc PG 19 relnotes: more fixes

  6. doc PG 19 relnotes: various corrections

  7. doc PG 19 relnotes: adjust item to mention pg_replication_slots

  8. doc PG 19 relnotes: remove "Add fake LSN support to hash index"

  9. doc PG 19 relnotes: add two optimizer hooks

  10. doc PG 19 relnotes: remove "Optionally" for CPU optimizations

  11. doc PG 19 relnotes: adjustments/removal of items

  12. doc PG 19 relnotes: add UTF-8 case folding performance item

  13. doc PG 19 relnotes: correct two items

  14. doc PG 19 relnotes: add missing commits and details

  15. doc PG 19 relnotes: fix typo, "date" -> "data"

  16. doc PG 19 relnotes: add author and move items

  17. doc PG 19 relnotes: update author

  18. doc PG 19 relnotes: add free space map all-visible item

  19. doc PG 19 relnotes: remove "Lakshmi N" as author of checksums

  20. doc PG 19 relnotes: fix "now targets"

  21. doc PG 19 relnotes: adjust ShmemRequestStruct item

  22. Improve various new-to-v19 appendStringInfo calls

  23. doc: Fix data_checksums data type

  24. Fix WITHOUT OVERLAPS' interaction with domains.

  25. Online enabling and disabling of data checksums

  26. Doc: split functions-posix-regexp section into multiple subsections.

  27. make immutability tests in to_json and to_jsonb complete

  28. Optimize tuple deformation

  29. pgstattuple: Optimize pgstattuple_approx() with streaming read

  30. Use fake LSNs to improve nbtree dropPin behavior.

  31. Use streaming read for VACUUM cleanup of GIN

  32. Clean up ICU includes.

  33. ICU: use UTF8-optimized case conversion API

  34. Add the MODE option to the WAIT FOR LSN command

  35. Speedup tuple deformation with additional function inlining