From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Subject: | Re: WIP: Faster Expression Processing v4 |
Date: | 2017-03-15 19:58:38 |
Message-ID: | 20170315195838.2dqr2v674u4qwxw4@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-03-15 15:41:22 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On March 15, 2017 12:33:28 PM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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, and it'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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-03-15 20:07:14 | Re: WIP: Faster Expression Processing v4 |
Previous Message | Tom Lane | 2017-03-15 19:57:53 | Re: Odd listen_addresses behavior |