Horton
Menu

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Andres Freund <andres@anarazel.de>
Cc: David Geier <geidav.pg@gmail.com>, PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-19T17:53:08Z
Lists: pgsql-hackers 
On Sun, Apr 19, 2026 at 11:10:40AM -0400, Andres Freund wrote:
> Hi,
> 
> On 2026-04-19 09:32:45 -0400, Bruce Momjian wrote:
> > On Sun, Apr 19, 2026 at 01:27:10PM +0200, David Geier wrote:
> > > >>> So, it seems there is no user-visible change, except it is faster.  Does
> > > >>> it enable new workloads?  A 3x speedup probably does.  Should this be a
> > > >>> pg_trgm item, with a description mentioning GIN in general, or should it
> > > >>> be a GIN item, perhaps mentioning pg_trgm?  Do you have any suggested
> > > >>> text and list of commits?
> > > >>
> > > >> Not all patches from the initial mail have been committed yet. Hence,
> > > >> currently the speed up is less. However, once they got all committed
> > > >> they would indeed open up new "use cases". For example, I know users
> > > >> that don't add GIN indexes to very large tables because creating them
> > > >> takes too long.
> > > > 
> > > > Yes, GIN index creation has always been considered slow, so it is good
> > > > it is being worked on.  I wonder if we should just wait for it all to be
> > > > committed before adding it to the release notes, unless you want to
> > > > measure the improvement we have in PG 19.
> > > 
> > > I've measured with the same benchmark I used in the original thread [1].
> > > With latest master the results are as follows:
> > > 
> > > Dataset  | REL_18_3   | master     | Speedup
> > > ---------|------------|------------|--------
> > > movies   |  10,561 ms |   9,124 ms | 1.17x
> > > lineitem | 263,523 ms | 234,605 ms | 1.12x
> > > 
> > > That's because three patches from the patchset haven't been committed
> > > yet. Two of the three patches are the most impactful from the patchset.
> > 
> > Okay, at +12-17%, so we should wait until all the patches are in to
> > mention this.  Thanks.
> 
> That makes no sense to me.  It's a material improvement that could convince
> people to upgrade.  Why would you not want to mention that, just because PG 20
> might have further improvements? There *always* will be further potential
> improvements.

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.

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