Horton
Menu

Re: First draft of PG 19 release notes

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: David Geier <geidav.pg@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-19T13:32:45Z
Lists: pgsql-hackers 
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.

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