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.94.2) (envelope-from ) id 1uQZKn-00DYRk-Pu for pgsql-bugs@arkaria.postgresql.org; Sat, 14 Jun 2025 22:26:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uQZKl-00AO8w-AY for pgsql-bugs@arkaria.postgresql.org; Sat, 14 Jun 2025 22:26:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uQZKl-00AO8o-28 for pgsql-bugs@lists.postgresql.org; Sat, 14 Jun 2025 22:26:43 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uQZKj-0025Go-1D for pgsql-bugs@lists.postgresql.org; Sat, 14 Jun 2025 22:26:43 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 55EMQb3a049487; Sat, 14 Jun 2025 18:26:38 -0400 From: Tom Lane To: Lowell Hought cc: Laurenz Albe , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18950: pgsql function that worked in Postgresql 16 does not return in Postgresql 17 In-reply-to: References: <75D714EA-CD1E-4F80-A2E8-29E378EC2200@gmail.com> <81946.1749348479@sss.pgh.pa.us> <89144.1749352271@sss.pgh.pa.us> <90964.1749353175@sss.pgh.pa.us> <1628600.1749914148@sss.pgh.pa.us> <1634855.1749917537@sss.pgh.pa.us> Comments: In-reply-to Lowell Hought message dated "Sat, 14 Jun 2025 16:35:20 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <49485.1749939997.1@sss.pgh.pa.us> Date: Sat, 14 Jun 2025 18:26:37 -0400 Message-ID: <49486.1749939997@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Lowell Hought writes: > Attached in three separate files. Thanks. The only thing that's really obvious here is that the rowcount estimates must be way off, because if the join outputs were as small as the planner thinks, this query couldn't take very long at all. I wonder whether your v17 installation is lacking appropriate statistics. By now autovacuum should have mostly filled that in even if you forgot to see to it when transferring data --- but maybe you had larger-than-default statistics targets in the v16 installation? Or some other change to the default settings? I'd double-check that and then do a manual ANALYZE of the whole database, and see if anything changes. regards, tom lane