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 Geier <geidav.pg@gmail.com>, PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-19T19:25:42Z
Lists: pgsql-hackers 
On 2026-04-19 14:36:57 -0400, Bruce Momjian wrote:
> On Sun, Apr 19, 2026 at 02:04:34PM -0400, Andres Freund wrote:
> > Hi,
> > 
> > On 2026-04-19 13:53:08 -0400, Bruce Momjian wrote:
> > > The text I put in the wiki, which I have followed for years, says:
> > >
> > > 	https://wiki.postgresql.org/wiki/Creating_Major_Release_Notes
> > > 	Performance improvements are mentioned in the release notes if
> > > 	they are user-visible (e.g., new syntax) or significant enough
> > > 	to enable new workloads.
> > >
> > > I didn't think +12-17% for an index build would enable new workloads.
> > > If you want to relitigate that, you are welcome to do so.  If this is
> > > changed, it has to be done so consistently, not just for this item.
> > 
> > Just about everyone has disagreed vehemently with you about this, in every of
> > the last 5 releases or so.  I don't think it's ok that you continue to ignore
> > that.
> 
> That is not my recollection, and I thought I would have heard more about
> it if that was the case.

I don't know what to tell you. Just looking at emails to you with a subject
that contains release and a body that contains performance quickly unearthed:

Tom:
https://postgr.es/m/568104.1716520270@sss.pgh.pa.us

Jonathan:
https://postgr.es/m/29a7dd7b-cb55-4c3c-8eba-faeca222b10b@postgresql.org

Alvaro:
https://postgr.es/m/202405150838.sg5ddcexyyf4@alvherre.pgsql

David:
https://postgr.es/m/CAApHDvrun6b+cAj6bgb6_1irnu+t7GU_uCdj1XvMQsPT0KngkQ@mail.gmail.com

Melanie:
https://postgr.es/m/CAAKRu_YKDQG1qA-eRq+gf5uoXZ3s9Jm3af9k3yF7WdKr2eTqLA@mail.gmail.com

Joe:
https://postgr.es/m/c276a2e5-a7ef-410d-832e-6fe54137e86d@joeconway.com

Jelte:
https://postgr.es/m/CAGECzQTp5TW+YzihDdPDuZN6q_uNWL_iCi5uxN2AjGPLOJh=Mg@mail.gmail.com

Peter G:
https://postgr.es/m/CAH2-Wzkgyak_ni0u24r1v3nhM1gVfx68-7-ZX1yZB+zcojMdnw@mail.gmail.com

Robert:
https://postgr.es/m/CA+TgmobqYx=+1RDsD7w9r_pfTa-CgJ6_Aj0SNaA6UKHQGyT9vg@mail.gmail.com

Noah:
20180505061321.GA2832545@rfd.leadboat.com

me:
https://postgr.es/m/20240524175028.lul7tpbngjlemy7j@awork3.anarazel.de


That's just a small sample.  I think nearly everybody said so in multiple
releases.  The argument goes back to at least 9.5...




> > I find this policy so depressing that I stopped even opening the release
> > notes, just to preserve whatever semblance of sanity I possess.  I'm know I'm
> > not alone in that.
> 
> Well, I just merged the wiki text to explain that we have to consider
> how much an item is of interest when adding it:
> 
> 	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.  Performance improvements are mentioned in the release
> 	notes if they are user-visible (e.g., new syntax) or significant
> 	enough to enable new workloads.

I think you're again documenting things as consensus for which there is not
concensus.


> So, if you want to change this process, please feel free to get
> agreement on new text that I can follow, or someone else can follow.

s/if they are user-visible (e.g., new syntax) or//
s/enough to enable new workloads//


> I have always hesitated to expand the list of items with concern that
> general Postgres users will lose interest in reading it.  I have in mind
> that the release notes are not for me or hackers subscribers to read.

Yes, which is precisely why they should be able to read the release notes to
see if an upgrade might address their performance issue. They can't
realistically be expected to read all commit messages or the list.


> I think we expanded the the list for optimizer changes.  Could we find a
> way to do that more that would be readable?  I don't know.

I don't think mentioning a few performance improvements when we do mention
things like "Modify psql backslash commands to show comments", "Allow the
search path to appear in the psql prompt via "%S", "Add IO wait events for
COPY FROM/TO on a pipe/file/program", ... makes a material negative
difference.

If we want to make the release notes easier to grasp, I could imagine that
giving each bullet point an icon indicating whether it's a feature, a
performance improvement, a behavioural change or such could make it easier to
scan.

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