Re: [HACKERS] WIP: Faster Expression Processing v4 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] WIP: Faster Expression Processing v4
Date
Msg-id 20170315195838.2dqr2v674u4qwxw4@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] WIP: Faster Expression Processing v4  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] WIP: Faster Expression Processing v4  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2017-03-15 15:41:22 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On March 15, 2017 12:33:28 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> So for my money, you should drop 0002 altogether and just have 0004
> >> remove get_last_attnums() from execUtils.c and stick it into
> >> execExpr.c.  I suppose you still need the LastAttnumInfo API change
> >> so as to decouple it from ProjectionInfo, but that's minor.
> 
> > I think it's quite useful in other places too, we do repeated slot-getattrs in a bunch of places in the executor,
andit's noticeable performance wise. 
 
> 
> Color me dubious.  Which specific other places have you got in mind, and
> do they have expression trees at hand that would tell them which columns
> they really need to pull out?

I was thinking of execGrouping.c's execTuplesMatch(),
TupleHashTableHash() (and unequal, but doubt that matters
performancewise).  There's also nodeHash.c's ExecHashGetValue(), but I
think that'd possibly better fixed differently.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Odd listen_addresses behavior
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] WIP: Faster Expression Processing v4