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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers