Re: make Gather node projection-capable

On 22 October 2015 at 16:01, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> If we make Gather projection-capable,
> we can just end up with Gather->PartialSeqScan.
>

Is there a reason not to do projection in the Gather node? I don't see one.

> > 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?
>
> The planner doesn't seem to choose to do projection in the innermost
> node possible. The final tlist only gets projected at the top of the
> join tree. Beneath that, it seems like we project in order to avoid
> carrying Vars through nodes where that would be a needless expense,
> but that's just dropping columns, not computing anything. That having
> been said, I don't think that takes anything away from your chain of
> reasoning here, and I agree with your conclusion. There seems to be
> little reason to force a Result node atop a Gather node when we don't
> do that for most other node types.
>

Presumably this is a performance issue then? If we are calculating
something *after* a join which increases rows then the query will be slower
than need be.

I agree the rule should be to project as early as possible.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services