Horton
Menu

Re: First draft of PG 19 release notes

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Bruce Momjian <bruce@momjian.us>
Cc: David Rowley <dgrowleyml@gmail.com>, David Geier <geidav.pg@gmail.com>, PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-21T15:52:37Z
Lists: pgsql-hackers 
Hi,

On 2026-04-20 12:12:07 -0400, Bruce Momjian wrote:
> On Mon, Apr 20, 2026 at 10:40:13PM +1200, David Rowley wrote:
> > 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.
> 
> So, these are not really rules, but a suggestion to just include more
> and we can trim.  I see several problems with that:
> 
> 1.  Researching and writing each item is what takes the most time, so it
> could double my time to do this, which is fine if there were not other
> problems.

FWIW, I think it's totally fine if you say that you don't want to do the work
to formulate performance improvement release note entries.  It's a lot of work
to curate the release notes, it makes sense to split the work up.

It's just that the answer to proposing listing certain performance
improvements shouldn't be that we don't include them as a matter of policy.


> It is only April 20.  We still have time for someone to start from
> scratch and make a new version.

I don't see any need to start from scratch! That'd be foolish imo, it's a lot
of work to get to this point.

Greetings,

Andres Freund

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