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.96) (envelope-from ) id 1w7dIK-005Xru-0L for pgsql-bugs@arkaria.postgresql.org; Tue, 31 Mar 2026 17:54:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w7dIH-00Bvf6-1y for pgsql-bugs@arkaria.postgresql.org; Tue, 31 Mar 2026 17:54:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w7dIH-00Bvey-19 for pgsql-bugs@lists.postgresql.org; Tue, 31 Mar 2026 17:54:25 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w7dID-00000002DGm-1tkG for pgsql-bugs@lists.postgresql.org; Tue, 31 Mar 2026 17:54:25 +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 62VHsGmx2734943; Tue, 31 Mar 2026 13:54:16 -0400 From: Tom Lane To: Justin Christensen cc: David Rowley , pgsql-bugs@lists.postgresql.org Subject: Re: Surprising behavior with pushing predicates down into a view In-reply-to: References: Comments: In-reply-to Justin Christensen message dated "Tue, 31 Mar 2026 11:00:09 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2734941.1774979656.1@sss.pgh.pa.us> Date: Tue, 31 Mar 2026 13:54:16 -0400 Message-ID: <2734942.1774979656@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Justin Christensen writes: > Ah. I did happen to skim the postgres source and I did see that subplans > were being rejected in qual_is_pushdown_safe before I sent this over, and I > noticed a few comments that made it seem like that was a design choice at > the time that could stand to be revisited later: "XXX that could stand to > be reconsidered, now that we use Paths." Actually the relevant comment is this one: * 1. rinfo's clause must not contain any SubPlans (mainly because it's * unclear that it will work correctly: SubLinks will already have been * transformed into SubPlans in the qual, but not in the subquery). Somebody who was sufficiently determined could probably make that happen, but it's very unclear how much code and messiness would be required. Another potential path is to make SubLink->SubPlan transformations happen later, after this step --- but I think that would metastasize into a lot of places, and possibly have some downsides in plan quality. Short answer is that we might well end up rejecting such a patch even if it got written. This limitation is decades old, and there have not been that many complaints, so I doubt we'd accept any large increase in complexity to remove it. regards, tom lane