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/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services