From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 22:06:10 |
Message-ID: | 20170315220610.wx6pzmsbdjf5a7gs@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-03-15 17:33:46 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-03-15 22:15:04 | Re: scram and \password |
Previous Message | Andrew Gierth | 2017-03-15 21:51:55 | Re: Hash support for grouping sets |