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-19T15:10:40Z
Lists: pgsql-hackers 
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.

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