On 2017-03-15 17:33:46 -0400, Tom Lane wrote: > 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 think those are often related (i.e. we replace a smaller targetlist with a "physical" one, which then allows to skip ExecProject()). > I've thought for some time that it was dumb to have the executor > reverse-engineering this info at plan startup anyway. Yea, it'd be good if this (and some similar tasks like building interim tuple descriptors) could be moved to the planner. But: > 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. probably isn't sufficient - we build non-virtual tuples in a good number of places (sorts, tuplestore using stuff like nodeMaterial, nodeHash.c output, ...). I suspect it'd have measurable negative consequences if we removed the deforming logic for all expressions/projections above such nodes. I guess we could just do such a logic for every Plan node? - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers