On 22 October 2015 at 16:01, Robert Haas <robertmh...@gmail.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
