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 1oHT8p-0006ik-Oe for pgsql-hackers@arkaria.postgresql.org; Fri, 29 Jul 2022 16:47:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oHT8o-0007q1-Aq for pgsql-hackers@arkaria.postgresql.org; Fri, 29 Jul 2022 16:47:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oHT8o-0007ps-0q for pgsql-hackers@lists.postgresql.org; Fri, 29 Jul 2022 16:47:10 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oHT8l-0000HW-Jf for pgsql-hackers@postgresql.org; Fri, 29 Jul 2022 16:47:08 +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 26TGl5Pi3819650; Fri, 29 Jul 2022 12:47:05 -0400 From: Tom Lane To: Robert Haas cc: Amit Langote , Jacob Champion , Zhihong Yu , David Rowley , PostgreSQL-development Subject: Re: generic plans and "initial" pruning In-reply-to: References: <215356.1647286703@sss.pgh.pa.us> ! <3633494.1659070517@sss.pgh.pa.us> <3772667.16591 Comments: In-reply-to Robert Haas message dated "Fri, 29 Jul 2022 11:56:02 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3819648.1659113225.1@sss.pgh.pa.us> Date: Fri, 29 Jul 2022 12:47:05 -0400 Message-ID: <3819649.1659113225@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > ... it's > always struck me as a little unfortunate that we basically test > whether a var is equal by testing whether the varno and varlevelsup > are equal. That only works if you assume that you can never end up > comparing two vars from thoroughly unrelated parts of the tree, such > that the subquery one level up from one might be different from the > subquery one level up from the other. Yeah, that's always bothered me a little as well. I've yet to see a case where it causes a problem in practice. But I think that if, say, we were to try to do any sort of cross-query-level optimization, then the ambiguity could rise up to bite us. That might be a situation where a flat rangetable would be worth the trouble. > I'm just uncertain whether what Amit has implemented is the > least-annoying way to go about it... any thoughts on that, > specifically as it pertains to this patch? I haven't looked at this patch at all. I'll try to make some time for it, but probably not today. regards, tom lane