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 1qqFFf-008pze-EM for pgsql-bugs@arkaria.postgresql.org; Tue, 10 Oct 2023 16:06:31 +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 1qqFFc-008nWE-9X for pgsql-bugs@arkaria.postgresql.org; Tue, 10 Oct 2023 16:06:29 +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 1qqFFc-008nW4-0C for pgsql-bugs@lists.postgresql.org; Tue, 10 Oct 2023 16:06:28 +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 1qqFFW-000yhf-Oc for pgsql-bugs@lists.postgresql.org; Tue, 10 Oct 2023 16:06:27 +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 39AG6KXG335647; Tue, 10 Oct 2023 12:06:21 -0400 From: Tom Lane To: lauri.kajan@gmail.com cc: pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18152: Join condition is not pushed down to union all subquery In-reply-to: <18152-72d0fe42ca4283d9@postgresql.org> References: <18152-72d0fe42ca4283d9@postgresql.org> Comments: In-reply-to PG Bug reporting form message dated "Tue, 10 Oct 2023 06:26:26 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <335645.1696953980.1@sss.pgh.pa.us> Date: Tue, 10 Oct 2023 12:06:20 -0400 Message-ID: <335646.1696953980@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk PG Bug reporting form writes: > The join condition is not pushed down to a subquery containing UNION ALL > when even a single query within the subquery contains a WHERE clause. I think this is less about "can't push down" than "can't pull up", specifically that prepjointree.c fails to flatten that subquery into an "appendrel member", per the comments in is_safe_append_member: * It's only safe to pull up the child if its jointree contains exactly * one RTE, else the AppendRelInfo data structure breaks. The one base RTE * could be buried in several levels of FromExpr, however. Also, if the * child's jointree is completely empty, we can pull up because * pull_up_simple_subquery will insert a single RTE_RESULT RTE instead. * * Also, the child can't have any WHERE quals because there's no place to * put them in an appendrel. (This is a bit annoying...) I don't recall at the moment if there are fundamental reasons not to have per-child quals in appendrels, or if it could be done with the application of enough elbow grease. But it's probably not trivial. That comment has been there quite awhile. regards, tom lane