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 1uO6JC-00Evuc-6j for pgsql-bugs@arkaria.postgresql.org; Sun, 08 Jun 2025 03:02:54 +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 1uO6JA-00GUb9-5l for pgsql-bugs@arkaria.postgresql.org; Sun, 08 Jun 2025 03:02:52 +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.94.2) (envelope-from ) id 1uO6J9-00GUb0-TZ for pgsql-bugs@lists.postgresql.org; Sun, 08 Jun 2025 03:02:52 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uO6J8-000qT5-38 for pgsql-bugs@lists.postgresql.org; Sun, 08 Jun 2025 03:02:51 +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 55832ma1088317; Sat, 7 Jun 2025 23:02:48 -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> Comments: In-reply-to Lowell Hought message dated "Sat, 07 Jun 2025 21:57:27 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <88315.1749351768.1@sss.pgh.pa.us> Date: Sat, 07 Jun 2025 23:02:48 -0400 Message-ID: <88316.1749351768@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Lowell Hought writes: > Yes! I just changed the parameter as you suggested and the query returned > as expected. > So I guess something changed between version 16 and version 17? Perhaps > the default for that setting? No, that default has not changed. What apparently happened is that cost estimates or something changed enough to persuade the planner to use a generic plan that's considerably inferior to what it was choosing before. There's nowhere near enough info in your report to pin it down more closely than that. Just to eliminate the obvious --- you did run ANALYZE after the upgrade, right? If you had any nondefault settings of default_statistics_target or similar planner parameters, did you make sure they got transferred to the new installation? regards, tom lane