Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1coHkN-0007hH-5j for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Mar 2017 22:50:23 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1coHkM-0004cQ-77 for pgsql-hackers@arkaria.postgresql.org; Wed, 15 Mar 2017 22:50:22 +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.84_2) (envelope-from ) id 1coHiq-0001uO-F5 for pgsql-hackers@postgresql.org; Wed, 15 Mar 2017 22:48:48 +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.84_2) (envelope-from ) id 1coHij-0001t8-KO for pgsql-hackers@postgresql.org; Wed, 15 Mar 2017 22:48:47 +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 v2FMmSoY010200; Wed, 15 Mar 2017 18:48:28 -0400 From: Tom Lane To: Andres Freund cc: pgsql-hackers@postgresql.org, Heikki Linnakangas , Tomas Vondra Subject: Re: WIP: Faster Expression Processing v4 In-reply-to: <20170315222236.dw762ndavazinau4@alap3.anarazel.de> References: <20170314224706.nxvtapenky6eom3z@alap3.anarazel.de> <3086.1489606408@sss.pgh.pa.us> <855716B2-7522-4C79-A50E-2EB8E609764F@anarazel.de> <3401.1489606882@sss.pgh.pa.us> <20170315195838.2dqr2v674u4qwxw4@alap3.anarazel.de> <4542.1489608434@sss.pgh.pa.us> <20170315205732.bwb2wh5o5ix2vv4b@alap3.anarazel.de> <7583.1489613626@sss.pgh.pa.us> <20170315220610.wx6pzmsbdjf5a7gs@alap3.anarazel.de> <9137.1489616217@sss.pgh.pa.us> <20170315222236.dw762ndavazinau4@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Wed, 15 Mar 2017 15:22:36 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10198.1489618108.1@sss.pgh.pa.us> Date: Wed, 15 Mar 2017 18:48:28 -0400 Message-ID: <10199.1489618108@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Andres Freund writes: > On 2017-03-15 18:16:57 -0400, Tom Lane wrote: >> [ scratches head... ] What deforming logic do you think I'm proposing >> removing? > I thought you were suggesting that we don't do the get_last_attnums (and > inlined version in the isSimpleVar case) at execution time anymore, > instead relying on logic in the planner to know how much to deform ahead > of time. Then we'd do slot_getsomeattrs in the appropriate places. But > I understood you suggesting to do so only in scan nodes - which doesn't > seem sufficient, due to the use of materialized / minimal tuples in > other types of nodes. Did I misunderstand? We would need to do it anywhere that we might be projecting from a materialized tuple, I suppose. From the planner's standpoint it would be about as easy to do this for all plan nodes as only selected ones. Anyway the core point here seems to be that skipping ExecProject misses a bet because the underlying tuple doesn't get disassembled. A quick-hack way of seeing if this helps might be to do slot_getallattrs in the places where we skip ExecProject. I'm not sure we'd want that as a permanent solution, because it's possible that it extracts columns not actually needed, but it should at least move the hotspot in your example case. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers