Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1crEUk-0005We-9Y for pgsql-hackers@arkaria.postgresql.org; Fri, 24 Mar 2017 01:58:26 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1crEUj-0002uS-4e for pgsql-hackers@arkaria.postgresql.org; Fri, 24 Mar 2017 01:58:25 +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 1crEUh-0002t5-FT for pgsql-hackers@postgresql.org; Fri, 24 Mar 2017 01:58:23 +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 1crEUZ-0001TH-Lq for pgsql-hackers@postgresql.org; Fri, 24 Mar 2017 01:58:22 +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 v2O1w3v3031826; Thu, 23 Mar 2017 21:58:03 -0400 From: Tom Lane To: Andres Freund cc: Heikki Linnakangas , Tomas Vondra , pgsql-hackers@postgresql.org Subject: Re: WIP: Faster Expression Processing v4 In-reply-to: <20170324013412.qy7ltnnqv5m7qiuc@alap3.anarazel.de> References: <20170320062511.hp5qeurtxrwsvfxr@alap3.anarazel.de> <31150.1490193666@sss.pgh.pa.us> <20170322145240.vt2iolwt6vpmx33z@alap3.anarazel.de> <31922.1490194838@sss.pgh.pa.us> <28270.1490289299@sss.pgh.pa.us> <20170323174004.a2ez7kygx5ngqxlp@alap3.anarazel.de> <8011.1490305255@sss.pgh.pa.us> <26088.1490315792@sss.pgh.pa.us> <20170324004734.3a2dokbfofiz6ylu@alap3.anarazel.de> <30270.1490318779@sss.pgh.pa.us> <20170324013412.qy7ltnnqv5m7qiuc@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Thu, 23 Mar 2017 18:34:12 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31824.1490320683.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Mar 2017 21:58:03 -0400 Message-ID: <31825.1490320683@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-23 21:26:19 -0400, Tom Lane wrote: >> Hmm, I see ... but that only works in the cases where the caller of >> ExecBuildProjectionInfo supplied a source slot, and a lot of 'em >> don't. > Right, the old and new code comment on that: > * inputDesc can be NULL, but if it is not, we check to see whether simple > * Vars in the tlist match the descriptor. It is important to provide > * inputDesc for relation-scan plan nodes, as a cross check that the rela= tion > * hasn't been changed since the plan was made. At higher levels of a pl= an, > * there is no need to recheck. Ah, I'd forgotten the assumption that we only need to check this at scan level. >> I'd already put in the infrastructure to add ASSIGN_FOO_VAR_FIRST >> step types. I could take it back out, but I wonder if it wouldn't be >> smarter to keep it and remove the restriction in ExecBuildProjectionInfo. >> Or maybe we could have ExecBuildProjectionInfo emit either >> ASSIGN_FOO_VAR_FIRST or ASSIGN_FOO_VAR depending on whether it can prove >> the reference safe. > I think it's probably ok to just leave the check in, and remove those > comments, and simplify the isSimpleVar stuff to only check if > IsA(tle->expr, Var) && ((Var *) tle->expr)->varattno > 0) Not sure. It's a pretty fair amount of duplicative code, once you finish dealing with all the ExecJustFoo functions in addition to the main code paths. At this point I'm inclined to take it back out and improve the comments around ExecBuildProjectionInfo. regards, tom lane --=20 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers