Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f5bXH-0008Hq-Sa for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Apr 2018 18:28:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f5bXF-0004Af-TX for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Apr 2018 18:28:57 +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 1f5bXF-0004AV-MV for pgsql-hackers@lists.postgresql.org; Mon, 09 Apr 2018 18:28:57 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f5bXA-000357-Jp for pgsql-hackers@postgresql.org; Mon, 09 Apr 2018 18:28:56 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 6EF211690; Mon, 9 Apr 2018 14:28:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 09 Apr 2018 14:28:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=BTi8T3Pod2hBZWrNK hd7c07n0eRh+PSbFvY64Z+l85o=; b=XtXT/JJ09pd/TsD/X9noZaj0YEHteHn9m eDrXYzG0luhk4NWgqZisiJ92bpaGy6zake6YQYgfy7JyKHtRfzjfOW0Asrv6sOrI cEOTFkD2wBDCV2zmyewMycomTbXdX+CYZAJCoCPXTTHkdihCMtDqBmSeF0SgKfYX P88Ojkl2KVAoeiLhL3tHXbyHhjgM2kf12f7Rf86cgaekUvaARiongqq57WsbItIg 2BTA7btQy0ZWTlpyTqVSyj7Zgs/GJQWNpx1UYEI1LygT9Tf4sMPS3I1rpFV9LKuq j+b7V/GmhXULjPVaoatA/6zbBmdl5XjpTgdnA83VwHfnV/AhTqsVQ== X-ME-Sender: Received: from alvin.alvh.no-ip.org (unknown [179.56.29.253]) by mail.messagingengine.com (Postfix) with ESMTPA id 84328E508E; Mon, 9 Apr 2018 14:28:49 -0400 (EDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id B0A8F366; Mon, 9 Apr 2018 15:28:47 -0300 (-03) Date: Mon, 9 Apr 2018 15:28:47 -0300 From: Alvaro Herrera To: Robert Haas Cc: David Rowley , Amit Langote , Amit Langote , Jesper Pedersen , Rajkumar Raghuwanshi , Beena Emerson , amul sul , "pgsql-hackers@postgresql.org" , Dilip Kumar Subject: Re: [HACKERS] Runtime Partition Pruning Message-ID: <20180409182847.hf3znk7ium7kmdt2@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas wrote: > On Sat, Apr 7, 2018 at 5:13 PM, Alvaro Herrera wrote: > > I had reservations about a relation_open() in the new executor code. It > > seemed a bit odd; we don't have any other relation_open in the executor > > anywhere. However, setting up the pruneinfo needs some stuff from > > relcache that I don't see a reasonable mechanism to pass through > > planner. I asked Andres about it on IM and while he didn't endorse the > > patch in any way, his quick opinion was that "it wasn't entirely > > insane". I verified that we already hold lock on the relation. > > I don't get this. The executor surely had to (and did) open all of > the relations somewhere even before this patch. Yeah. I was worried that this coding could be seen as breaking modularity, or trying to do excessive work. However, after looking closer at it, it doesn't really look like it's the case. So, nevermind. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services