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 1sj5PL-00EKUe-Gq for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Aug 2024 23:15:27 +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 1sj5PJ-00E3QA-6u for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Aug 2024 23:15:25 +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 1sj5PI-00E3Q1-Qz for pgsql-hackers@lists.postgresql.org; Tue, 27 Aug 2024 23:15:25 +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.94.2) (envelope-from ) id 1sj5PG-001kxp-Sr for pgsql-hackers@lists.postgresql.org; Tue, 27 Aug 2024 23:15:24 +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 47RNFLf43156372; Tue, 27 Aug 2024 19:15:21 -0400 From: Tom Lane To: David Rowley cc: Richard Guo , nikhil raj , pgsql-hackers@lists.postgresql.org Subject: Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables. In-reply-to: References: <2962669.1724722813@sss.pgh.pa.us> <2965760.1724724227@sss.pgh.pa.us> <3104695.1724775341@sss.pgh.pa.us> <3147330.1724795532@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Wed, 28 Aug 2024 11:03:08 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3156370.1724800521.1@sss.pgh.pa.us> Date: Tue, 27 Aug 2024 19:15:21 -0400 Message-ID: <3156371.1724800521@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > On Wed, 28 Aug 2024 at 09:52, Tom Lane wrote: >> The other problem with this is that it breaks one test case in >> memoize.sql: a query that formerly generated a memoize plan >> now does not use memoize. I am not sure why not --- does that >> mean anything to you? > The reason it works in master is that get_memoize_path() calls > extract_lateral_vars_from_PHVs() and finds PlaceHolderVars to use as > the Memoize keys. With your patch PlannerInfo.placeholder_list is > empty. That seems like a pretty fishy way to do it. Are you saying that Memoize is never applicable if there aren't outer joins in the query? Without OJs there probably won't be any PHVs. regards, tom lane