Re: First draft of PG 19 release notes
| От | Bruce Momjian |
|---|---|
| Тема | Re: First draft of PG 19 release notes |
| Дата | |
| Msg-id | aeTZfV96OtDUO923@momjian.us обсуждение |
| Ответ на | Re: First draft of PG 19 release notes (David Geier <geidav.pg@gmail.com>) |
| Ответы |
Re: First draft of PG 19 release notes
|
| Список | 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.
В списке pgsql-hackers по дате отправления: