| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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 20:07:14 |
| Message-ID: | 4542.1489608434@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2017-03-15 20:20:04 | Re: Odd listen_addresses behavior |
| Previous Message | Andres Freund | 2017-03-15 19:58:38 | Re: WIP: Faster Expression Processing v4 |