Horton
Menu

Re: First draft of PG 19 release notes

David Rowley <dgrowleyml@gmail.com>

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

I imagine it's easier to prune away items that are not interesting
enough than to add ones that were skipped. Unless we get visibility of
ones that you skipped, it requires someone else to notice something is
missing (probably their own work), or it requires a complete parse of
all commits in the release.

> 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.

That's going to be tricky to define. 2x performance increase in
something like initdb isn't going to be nearly as interesting to an
end user as making joins or aggregation go twice as fast. Maybe it
would be worth putting temporary tags on items that there are no
obvious performance numbers for to tell the author or committer that
you need proof, otherwise the item might disappear. For items that
might be more borderline worth adding, maybe those could also get
added and tagged to trigger some debate as to if they're worth keeping
around. In the end, we might see what it is you see with the bloated
release notes. You might find you get more agreement to remove things.
That's seldom requested with the current method. It seems reasonable
that not many people can sympathise with the "there are too many
items" problem, as by the time the notes go public, they're already
trimmed down to a manageable number. We might find that we all agree
on more things if the pruning is done more publicly.

> 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.

I don't think anyone expects you to do anything that makes this job
harder than it already.  I expect a careful process change could make
this job easier for you.

> 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.

I wondered if the job could be made easier if we were to tag fixup
commits for commits that fix some recent feature commit. You could
pretty much ignore every single one of those for the release notes. If
that fixup information was more structured, it might also be very
interesting.

> 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."

If the WIP draft contained the items of lesser importance, we might be
able to do some aggregation of those into something meaningful enough.
It might be much easier for people closer to the particular items to
aggregate them than it is for a single person to do it for all
commits. I'm aware that you already do quite a bit of this aggregation
already.

David

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