Andres Freund <and...@anarazel.de> writes:
> On 2017-03-15 16:07:14 -0400, Tom Lane wrote:
>> 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.
> I think the physical tuple stuff commonly thwarts that argument? On
> master for tpch's Q5 you can e.g. see the following profile (master):
Hmmm ... I think you're mistaken in fingering the physical-tuple
optimization per se, but maybe skipping ExecProject at the scan level
would cause this result?
I've thought for some time that it was dumb to have the executor
reverse-engineering this info at plan startup anyway. We could make the
planner mark each table scan node with the highest column number that the
plan will access, and use that to drive a slot_getsomeattrs call in
advance of any access to tuple contents.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
