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 1fUxak-0007PX-Q0 for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Jun 2018 17:05:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fUxaj-0007mY-KO for pgsql-hackers@arkaria.postgresql.org; Mon, 18 Jun 2018 17:05:21 +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 1fUxaj-0007lw-9I for pgsql-hackers@lists.postgresql.org; Mon, 18 Jun 2018 17:05:21 +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 1fUxag-0006Yy-K3 for pgsql-hackers@lists.postgresql.org; Mon, 18 Jun 2018 17:05:19 +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 w5IH5B3L029988; Mon, 18 Jun 2018 13:05:11 -0400 From: Tom Lane To: Amit Langote cc: Robert Haas , David Rowley , Dmitry Dolgov <9erthalion6@gmail.com>, Jeff Janes , Ashutosh Bapat , Pavel Stehule , PostgreSQL Hackers Subject: Re: why partition pruning doesn't work? In-reply-to: <56f1556c-6d6e-aaf8-de4f-a790a1efa5a3@lab.ntt.co.jp> 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> <56f1556c-6d6e-aaf8-de4f-a790a1efa5a3@l! ab.ntt.co.jp> Comments: In-reply-to Amit Langote message dated "Fri, 15 Jun 2018 17:39:02 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29986.1529341511.1@sss.pgh.pa.us> Date: Mon, 18 Jun 2018 13:05:11 -0400 Message-ID: <29987.1529341511@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Langote writes: > [ 0001-Open-partitioned-tables-during-Append-initialization.patch ] I took a look at this. While I'm in agreement with the general idea of holding open the partitioned relations' relcache entries throughout the query, I do not like anything about this patch: * It seems to be outright broken for the case that any of the partitioned relations are listed in nonleafResultRelations. If we're going to do it like this, we have to open every one of the partrels regardless of that. (I wonder whether we couldn't lose PlannedStmt.nonleafResultRelations altogether, in favor of merging the related code in InitPlan with this. That existing code is already a mighty ugly wart, and this patch makes it worse by adding new, related warts elsewhere.) * You've got *far* too much intimate knowledge of the possible callers in ExecOpenAppendPartitionedTables. Personally, what I would have this function do is return a List of the opened Relation pointers, and add a matching function to run through such a List and close the entries again, and make the callers responsible for stashing the List pointer in an appropriate field in their planstate. Or maybe what we should do is drop ExecLockNonLeafAppendTables/ ExecOpenAppendPartitionedTables entirely and teach InitPlan to do it. regards, tom lane