Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cqhd4-0005Bg-H9 for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Mar 2017 14:52:50 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cqhd3-0003nK-OW for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Mar 2017 14:52:49 +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.84_2) (envelope-from ) id 1cqhd1-0003kr-S3 for pgsql-hackers@postgresql.org; Wed, 22 Mar 2017 14:52:47 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cqhcz-0006zK-A9 for pgsql-hackers@postgresql.org; Wed, 22 Mar 2017 14:52:47 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id E509D20C00; Wed, 22 Mar 2017 10:52:43 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 22 Mar 2017 10:52:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=G77alZcEh3Hh5Ai44y cLKxEWhzXzg9DvRmvpXsu1G2k=; b=mwfueJiqo5f68Ezt2SlyxhE0gR9AZqpQQS K6cxuduVrAUDVAiBG6XF7rl66GQFUaP0A5eQKi0+capPUxYrvQ6FwNAsQ/cb04Gy oOv+lJCf3t9prsb8bqMIoCogO0Q0+SwPAy/l4d5x2CcryVxVoedCeDFnoTHMKz0v 3a85BwZoy+msopPxm3bMWkU0vxWeov1y5Mioo6J1wW45bu5qf0XsCOeF4uGngQhn 09mPLRT34ir4ifNFylgC2Y0OfM7TsNvzBGhP6z4d7NyzqJ8ZEeDSB2DVuDVl/Lqi YdDROD22d+JUg6qCyZf2UHu0tJrEl+aetBedHMhnllYugTAvKpbw== X-ME-Sender: X-Sasl-enc: FYI4CnKKNCCBZySnxbG+BR8nyAaaDl19BovRt7OmgY4A 1490194363 Received: from intern.anarazel.de (unknown [172.56.13.151]) by mail.messagingengine.com (Postfix) with ESMTPA id 796B07E442; Wed, 22 Mar 2017 10:52:43 -0400 (EDT) Date: Wed, 22 Mar 2017 07:52:40 -0700 From: Andres Freund To: Tom Lane Cc: Heikki Linnakangas , Tomas Vondra , pgsql-hackers@postgresql.org Subject: Re: WIP: Faster Expression Processing v4 Message-ID: <20170322145240.vt2iolwt6vpmx33z@alap3.anarazel.de> References: <20170307030137.lpo4japv5oqgbqpz@alap3.anarazel.de> <2090fd00-4dec-7b42-f700-64308958504c@2ndquadrant.com> <20170313080351.4g5oubxcj4xj5y7t@alap3.anarazel.de> <20170314065259.ffef4tfhgbsaieoe@alap3.anarazel.de> <69b7bb0e-8dab-3d39-1a89-3c6ab6409f64@iki.fi> <20170314224706.nxvtapenky6eom3z@alap3.anarazel.de> <13062.1489622943@sss.pgh.pa.us> <20170320062511.hp5qeurtxrwsvfxr@alap3.anarazel.de> <31150.1490193666@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31150.1490193666@sss.pgh.pa.us> X-Pg-Spam-Score: -2.6 (--) 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 On 2017-03-22 10:41:06 -0400, Tom Lane wrote: > I've been busily hacking away on this, trying to make things cleaner and > fix a couple of bugs I stumbled across. (Confusion between ExecQual and > ExecCheck, for instance - we apparently lack regression tests exercising > constraints-returning-null in corner cases such as table rewrite.) It > will probably be a day or two more before I'm done. Thanks! > A couple of naming questions: > > * I concur with Heikki's dislike for the file name execInterpExpr.c. > Would it make it any better to switch to execExprInterp.c? I think > that having all this stuff under a common pattern execExpr*.c would > be a good thing (and I notice you've already got one comment referring > to them that way ...) That works for me. > * execQual.c doesn't seem to have a unifying reason to exist anymore. > It certainly has little to do with evaluating typical qual expressions; > what's left in there seems to be mostly concerned with SRFs. I feel > like it might be a good idea to rename it, but to what? execExprUtils.c > perhaps? Or maybe we should destroy it altogether, shoving the SRF > stuff into nodeFunctionscan.c and moving what little remains into > execUtils.c. Yea, I was wondering about that too. What would we do with GetAttributeByName/Num? > * I do not like the function name ExecInstantiateExpr(). Webster's > defines "instantiate" as "to represent (an abstraction) by a concrete > instance", which does not seem to me to have a lot to do with what this > function actually does. It perhaps makes a *bit* more sense if you view it from the POV that, with the future JIT support (WIP versions of which I posted previously), it'd actually create a compiled function which'd largely be independent of the of ->steps (except for the non-hotpath functions, which'd still end up using it). So one of the above "conrete instances" would be the interpeted version, another the compiled one. No, not an entirely convincing argument. > There's nothing very abstract about its input. > More, the implication of "instantiate" is that you can instantiate any > number of representatives of the same abstraction, but this scribbles > on the input in a one-way fashion. I think perhaps something like > ExecPrepareExpr or ExecFinishExpr or something along that line would > be better, but nothing is really standing out as le mot juste. Either of those work, but they don't strike me as perfect either, but I can't come up with something better (ExecReadyExprForExec()?). Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers