Re: make Gather node projection-capable

On Thu, Oct 22, 2015 at 1:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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