Re: make Gather node projection-capable

Robert Haas wrote:
> 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).

I don't understand your reply. Failing to parallelize the child node
does not prevent it from doing the projection itself, does it?

That said, I don't understand Tom's comment either. Surely the planner
is going to choose to do the projection in the innermost node possible,
so that the children nodes are going to do the projections most of the
time. But if for whatever reason this fails to happen, wouldn't it make
more sense to do it at Gather than having to put a Result on top?

> >> 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.

Projections are a weird construct as implemented, yeah. I imagine it's
because of performance reasons, because having separate Result nodes
everywhere would be a lot slower, wouldn't it?

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services