On Thu, Oct 22, 2015 at 1:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> The Gather node, as currently committed, is neither projection-capable >> nor listed as an exception in is_projection_capable_plan. Amit >> discovered this in testing, and I hit it in my testing as well. We >> could just mark it as being not projection-capable, but I think it >> might be better to go the other way and give it projection >> capabilities. > > Um ... why would you not want the projections to happen in the child > nodes, where they could be parallelized? Or am I missing something?
You probably would, but sometimes that might not be possible; for example, the tlist might contain a parallel-restricted function (which therefore has to run in the leader). >> While that's not the end of the world, it seems to needlessly fly in >> the face of the general principle that nodes should generally try to >> support projection. > > I'm not sure there is any such principle. I just inferred that this was the principle from reading the code; it doesn't seem to be documented anywhere. In fact, what projection actually means doesn't seem to be documented anywhere. Feel free to set me straight. That having been said, I hope there's SOME principle other than "whatever we happened to implement". All of our scan and join nodes seem to have projection capability - I assume that's not an accident. It would simplify the executor code if we ripped all of that out and instead had a separate Project node (or used Result), but for some reason we have not. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
