Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ntzfU-0003FB-6z for pgsql-bugs@arkaria.postgresql.org; Wed, 25 May 2022 22:39:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ntzfS-000090-WD for pgsql-bugs@arkaria.postgresql.org; Wed, 25 May 2022 22:39:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ntzfS-00008q-Nj for pgsql-bugs@lists.postgresql.org; Wed, 25 May 2022 22:39:50 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ntzfQ-0008Vb-N3 for pgsql-bugs@lists.postgresql.org; Wed, 25 May 2022 22:39:50 +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 24PMdkJT2026719; Wed, 25 May 2022 18:39:46 -0400 From: Tom Lane To: David Rowley cc: Richard Guo , Michael Paquier , jeremyevans0@gmail.com, PostgreSQL mailing lists Subject: Re: BUG #17495: Regression in 15beta1 when filtering subquery including row_number window function In-reply-to: References: <17495-7ffe2fa0b261b9fa@postgresql.org> Comments: In-reply-to David Rowley message dated "Thu, 26 May 2022 10:33:19 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2026717.1653518386.1@sss.pgh.pa.us> Date: Wed, 25 May 2022 18:39:46 -0400 Message-ID: <2026718.1653518386@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > Maybe a better fix is to add a new Bitmapset field to WindowClause and > have find_window_run_conditions() record the attno in that field when > it appends the new runCondition to the runCondition field. > remove_unused_subquery_outputs() can just bms_add_members that field > to attrs_used. This just means having to add a field to WindowClause > post-beta. Is that going to be a problem? It'd mean a forced initdb, which is not great, but unless 0ff20288e gets reverted there'd be no additional impact on beta testers. A bigger problem with what you describe is that I don't really think the planner should be mucking with the input parse tree like that. Can't we retain this information somewhere else instead, in storage associated with the PlannerInfo? regards, tom lane