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 1fSmZJ-0002qd-2p for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Jun 2018 16:54:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fSmZH-0006Hd-Pt for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Jun 2018 16:54:51 +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_SHA384:256) (Exim 4.89) (envelope-from ) id 1fSmZH-0006HU-Iq for pgsql-hackers@lists.postgresql.org; Tue, 12 Jun 2018 16:54:51 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fSmZF-0002Q0-1o for pgsql-hackers@lists.postgresql.org; Tue, 12 Jun 2018 16:54:51 +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 w5CGsf8E030982; Tue, 12 Jun 2018 12:54:41 -0400 From: Tom Lane To: Robert Haas cc: David Rowley , 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: <7142.1527868419@sss.pgh.pa.us> <1111.1527977170@sss.pgh.pa.us> <10432.1528045900@sss.pgh.pa.us> <569483c5-a273-6537-1b5d-7a271ce439fb@lab.ntt.co.jp> <22805.1528386192@sss.pgh.pa.us> <21787.1528428171@sss.pgh.pa.us> <12624.1528578026@! sss.pgh.pa.us> <26279.1528670981@sss.pgh.pa.us> <17850.1528755844@sss.pgh.pa.us> <19365.1528820758@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 12 Jun 2018 12:40:28 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30980.1528822481.1@sss.pgh.pa.us> Date: Tue, 12 Jun 2018 12:54:41 -0400 Message-ID: <30981.1528822481@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > I think we DO hold relations open for the duration of execution > (though not necessarily between planning and execution). And there is > code in RelationClearRelation to avoid changing rd_partkey and > rd_partdesc if no logical change has occurred. Testing with valgrind + RELCACHE_FORCE_RELEASE is sufficient to disprove that, cf current results from lousyjack (which match my own testing). The partkey *is* disappearing under us. While I've not looked into the exact reasons for that, my first guess is that the partitioned table is not held open because it's not one of the ones to be scanned. Are you prepared to change something like that at this stage of the release cycle? regards, tom lane