Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wEWKY-0046QY-2y for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Apr 2026 17:53:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wEWKW-00FjTH-1a for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Apr 2026 17:53:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wEWKW-00FjT8-0c for pgsql-hackers@lists.postgresql.org; Sun, 19 Apr 2026 17:53:12 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wEWKT-00000001nof-43WY for pgsql-hackers@lists.postgresql.org; Sun, 19 Apr 2026 17:53:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2026010100; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=UW4QlRmUrNLURMO6FTz6/JoSJnG3Zn1rtI1IGp3apdw=; b=5pmck TVkk3hbWxjcxYzrEvILOhF/+vg7lC9Zq3qsu6YuB/KwLqrXRD02T+HXD0icKPVTac+2yH2gTnPtnW tUVfOJ6jCU24ALp3Sv2194mXgqiANuNTOxELk27CHRKesP1Eg/tfomHj4AUEoh1PJGN6t+GLfdBJy 2SFpeRG6vPJQAQR+mjpY7E75jQ0JW534czwNDkvdqd6+YKyd6BGPXp707x2zTO/UTnReQR/T90YcJ +VFts4BfNPaoDoAdRtFlKsZCMfmwkS3RqE7E0OSal+ZxRCFUeNaSejp23MDss2az2cWEbS7m31/RJ vqAS4m5aLg6xYDCzgPt5Sz2dPZGHw==; Received: from bruce by momjian.us with local (Exim 4.98.2) (envelope-from ) id 1wEWKS-00000005xaG-3Y4S; Sun, 19 Apr 2026 13:53:08 -0400 Date: Sun, 19 Apr 2026 13:53:08 -0400 From: Bruce Momjian To: Andres Freund Cc: David Geier , PostgreSQL-development Subject: Re: First draft of PG 19 release notes Message-ID: References: <5d58c42f-11e2-432c-a926-49d16d890c99@gmail.com> <79bc2b67-b0c1-4945-a5df-1b4f71d32a48@gmail.com> <3407474c-9154-43b8-bff3-0cb3ebe53934@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Apr 19, 2026 at 11:10:40AM -0400, Andres Freund wrote: > 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. The text I put in the wiki, which I have followed for years, says: https://wiki.postgresql.org/wiki/Creating_Major_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. I didn't think +12-17% for an index build would enable new workloads. If you want to relitigate that, you are welcome to do so. If this is changed, it has to be done so consistently, not just for this item. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.