| From: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: First draft of PG 19 release notes |
| Date: | 2026-04-19 11:27:10 |
| Message-ID: | 3407474c-9154-43b8-bff3-0cb3ebe53934@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>> 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.
[1]
https://www.postgresql.org/message-id/flat/5d366878-2007-4d31-861e-19294b7a583b%40gmail.com
--
David Geier
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2026-04-19 13:06:20 | Re: [PATCH] Fix hashed ScalarArrayOp semantics for NULL LHS with non-strict comparators |
| Previous Message | Alexander Lakhin | 2026-04-19 11:00:01 | Re: Adding REPACK [concurrently] |