Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fereY-0001S2-Q8 for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Jul 2018 00:46:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fereV-0006C4-Of for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Jul 2018 00:46:11 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fereV-0006Bx-Dk for pgsql-hackers@lists.postgresql.org; Mon, 16 Jul 2018 00:46:11 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fereO-00080t-GE for pgsql-hackers@lists.postgresql.org; Mon, 16 Jul 2018 00:46:10 +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 w6G0jstT015381; Sun, 15 Jul 2018 20:45:54 -0400 From: Tom Lane To: David Rowley cc: Robert Haas , Amit Langote , Dmitry Dolgov <9erthalion6@gmail.com>, Jeff Janes , Ashutosh Bapat , Pavel Stehule , PostgreSQL Hackers Subject: Re: why partition pruning doesn't work? In-reply-to: References: <22805.1528386192@sss.pgh.pa.us> <21787.1528428171@sss.pgh.pa.us> <17850.1528755844@sss.pgh.pa.us> <19365.1528820758@sss.pgh.pa.us> <30981.1528822481@sss.pgh.pa.us> <637.1528863347@sss.pgh.pa.us> <28597.1528900759@sss.pgh.pa.us> <27099.1528987211@sss.pgh.pa.us> <29987.1529341511@sss.pgh.pa.us> <4114.1531674142@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Mon, 16 Jul 2018 12:24:59 +1200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15379.1531701954.1@sss.pgh.pa.us> Date: Sun, 15 Jul 2018 20:45:54 -0400 Message-ID: <15380.1531701954@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk David Rowley writes: > On 16 July 2018 at 12:12, Robert Haas wrote: >> On Sun, Jul 15, 2018 at 1:02 PM, Tom Lane wrote: >>> What we'd be better off doing, if we go this route, is to install an >>> assertion-build-only test that verifies during relation_open(NoLock) >>> that some kind of lock is already held on the rel. > Wouldn't it be better to just store the Relation indexed by its relid > somewhere the first time we opened it? Then just do a direct array > lookup on that rather than looking up by hashtable in syscache? That would require carrying said array clear through from the parser to the executor, plus we'd have some fun keeping it in sync with the RTE changes that happen in the rewriter and planner, plus it's not entirely clear where we'd close those relations in cases where the generated plan isn't fed to the executor immediately (or gets copied in any way). I don't think it's worth going that far. I *do* think it might be worth behaving like that within the executor by itself, and said so upthread. In that situation, we have a clear place to do relation closes during ExecutorEnd, so it's not as messy as a more general approach would be. regards, tom lane