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 1pQeNI-0000Cx-7T for pgsql-bugs@arkaria.postgresql.org; Sat, 11 Feb 2023 01:08:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pQeNG-00068E-RE for pgsql-bugs@arkaria.postgresql.org; Sat, 11 Feb 2023 01:08:18 +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 1pQeNG-00067z-J1 for pgsql-bugs@lists.postgresql.org; Sat, 11 Feb 2023 01:08:18 +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 1pQeNE-0001Ss-4J for pgsql-bugs@lists.postgresql.org; Sat, 11 Feb 2023 01:08:18 +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 31B1897c451443; Fri, 10 Feb 2023 20:08:09 -0500 From: Tom Lane To: Andres Freund cc: xinwen@stu.scu.edu.cn, pgsql-bugs@lists.postgresql.org, David Rowley Subject: Re: BUG #17777: An assert failed in nodeWindowAgg.c In-reply-to: <20230211004940.t5l2dz7rnss76zao@awork3.anarazel.de> References: <17777-860b739b6efde977@postgresql.org> <20230210230230.scuk6gqrks6c7sc7@awork3.anarazel.de> <439391.1676070752@sss.pgh.pa.us> <20230210232051.efjhtoqo6odk3gke@awork3.anarazel.de> <443909.1676073430@sss.pgh.pa.us> <20230211004940.t5l2dz7rnss76zao@awork3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Fri, 10 Feb 2023 16:49:40 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <451441.1676077689.1@sss.pgh.pa.us> Date: Fri, 10 Feb 2023 20:08:09 -0500 Message-ID: <451442.1676077689@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > I think we could just add a !contain_subplans() to the code deciding whether > it's safe to use the movable window optimization? Yeah, perhaps. That doesn't seem like a mainstream use-case either. Another idea, tying into your previous point, is to try to check contain_volatile_functions in the planner before we've reduced sublinks to subplans. I'm not sure that would be convenient to do though; subplan-conversion happens pretty early. (I'm quite hesitant to move the goalposts on what contain_volatile_functions detects. As that comment indicates, some thought has gone into its current behavior, and I think we might hit some unwanted side-effects if we change it.) regards, tom lane