Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gNnTw-0007jk-RM for pgsql-hackers@arkaria.postgresql.org; Fri, 16 Nov 2018 23:25:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gNnTv-0000uq-7h for pgsql-hackers@arkaria.postgresql.org; Fri, 16 Nov 2018 23:24:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gNnTv-0000uj-0J for pgsql-hackers@lists.postgresql.org; Fri, 16 Nov 2018 23:24:59 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gNnTs-0006Eg-VT for pgsql-hackers@postgresql.org; Fri, 16 Nov 2018 23:24:58 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id wAGNOpFn010372; Fri, 16 Nov 2018 18:24:51 -0500 From: Tom Lane To: Andrew Gierth cc: Andreas Karlsson , David Fetter , Thomas Munro , Pg Hackers Subject: Re: Early WIP/PoC for inlining CTEs In-reply-to: <87in0wu0v9.fsf@news-spur.riddles.org.uk> References: <87sh48ffhb.fsf@news-spur.riddles.org.uk> <20180725054236.GB17411@fetter.org> <87bmavfjhy.fsf@news-spur.riddles.org.uk> <20180725191447.GE17411@fetter.org> <20180727081058.GN17411@fetter.org> <8810.1542402910@sss.pgh.pa.us> <87in0wu0v9.fsf@news-spur.riddles.org.uk> Comments: In-reply-to Andrew Gierth message dated "Fri, 16 Nov 2018 23:04:38 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10370.1542410691.1@sss.pgh.pa.us> Date: Fri, 16 Nov 2018 18:24:51 -0500 Message-ID: <10371.1542410691@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> * I have no faith in the idea that we can skip doing a copyObject > Tom> on the inlined subquery, except maybe in the case where we know > Tom> there's exactly one reference. > The code doesn't do a copyObject on the query if there are no level > changes because everywhere else just does another copyObject on it as > the first processing step (cf. set_subquery_pathlist and the various > functions called from pull_up_subqueries). Perhaps it's safe today, but is that likely to remain true? We've had enough pain in the past from multiply-linked parse subtrees that I am not eager to introduce another case, especially not here where there's absolutely no evidence that it'd provide a meaningful performance improvement. > Tom> * Speaking of the comments, I'm not convinced that view rewrite is > Tom> a good comparison point; I think this is more like subquery > Tom> pullup. > It's not really like subquery pullup because we actually do go on to do > subquery pullup _after_ inlining CTEs. Subquery pullup can happen across multiple levels, too. regards, tom lane