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 1pd0rL-0008Lj-Ap for pgsql-bugs@arkaria.postgresql.org; Fri, 17 Mar 2023 03:34:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pd0rI-00063F-U7 for pgsql-bugs@arkaria.postgresql.org; Fri, 17 Mar 2023 03:34:24 +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 1pd0rI-000636-Lq for pgsql-bugs@lists.postgresql.org; Fri, 17 Mar 2023 03:34:24 +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 1pd0rB-0000b8-IQ for pgsql-bugs@lists.postgresql.org; Fri, 17 Mar 2023 03:34: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 32H3YEp34087061; Thu, 16 Mar 2023 23:34:14 -0400 From: Tom Lane To: David Rowley cc: xinwen@stu.scu.edu.cn, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c In-reply-to: References: <17826-7d8750952f19a5f5@postgresql.org> <402866.1678378153@sss.pgh.pa.us> <1229467.1678555436@sss.pgh.pa.us> <1616392.1678657435@sss.pgh.pa.us> <3962534.1678993174@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Fri, 17 Mar 2023 16:11:39 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4087059.1679024054.1@sss.pgh.pa.us> Date: Thu, 16 Mar 2023 23:34:14 -0400 Message-ID: <4087060.1679024054@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > I kinda also wanted to do the attached so that the logic to push or > not to push was more centralised. I just couldn't figure out exactly > why we don't push down pseudoconstant quals, therefore, was unable to > document that sufficiently in the header comment in > qual_is_pushdown_safe(). A pseudoconstant qual turns into a filtering Result node with a one-time condition that controls whether it runs the child plan at all. You want to put those as high in the plan tree as possible, so that they cut off the maximum possible amount of work when the one-time condition is false. So pushing one down into a subplan would be downright counterproductive. regards, tom lane