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

From Tom Lane
Subject Re: [HACKERS] WIP: Faster Expression Processing v4
Date
Msg-id 4542.1489608434@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] WIP: Faster Expression Processing v4  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] WIP: Faster Expression Processing v4  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2017-03-15 15:41:22 -0400, Tom Lane wrote:
>> 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.

The execGrouping.c functions don't have access to an expression tree
instructing them which columns to pull out of the tuple, so I fail to see
how get_last_attnums() would be of any use to them.  As for
ExecHashGetHashValue, it's most likely going to be working from virtual
tuples passed up to the join, which won't benefit from predetermination
of the last column to be accessed.  The tuple-deconstruction would have
happened while projecting in the scan node below.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] WIP: Faster Expression Processing v4
Next
From: "Joshua D. Drake"
Date:
Subject: Re: [HACKERS] Odd listen_addresses behavior