Date: Fri, 17 Apr 2026 10:44:22 -0400
From: Bruce Momjian <bruce@momjian.us>
To: David Geier <geidav.pg@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Subject: Re: First draft of PG 19 release notes
Message-ID: <aeJHRqGC0SN7mubg@momjian.us>
References: <ad7ngXC125AvNqC2@momjian.us>
 <5d58c42f-11e2-432c-a926-49d16d890c99@gmail.com>
 <aeEKzO7sVZy_5Tzo@momjian.us>
 <79bc2b67-b0c1-4945-a5df-1b4f71d32a48@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <79bc2b67-b0c1-4945-a5df-1b4f71d32a48@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aeJHRqGC0SN7mubg%40momjian.us>
Precedence: bulk

On Fri, Apr 17, 2026 at 04:40:09PM +0200, David Geier wrote:
> > Now that you have told me about it, here is my normal criteria for
> > adding performance items to the 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.
> > 
> > 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.

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