Re: plan shape work

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Just a random thought, but another idea that crossed my mind here at
> one point was to actually split the Result node up into Result nodes
> with subplans and Result nodes without subplans. We could call the
> version with a subplan "Project" and the version without a subplan
> "Result", for example. This seems a little silly because both variants
> would need to be able to handle resconstantqual, or alternatively we'd
> have to be OK with getting "Project" on top of "Result" in some cases
> where a single "Result" node currently does both jobs. On the other
> hand, only Project needs a subplan, and only Result needs relids.

Maybe. I kinda feel that actually redesigning plan trees is outside
the scope of this project, but maybe we should consider it.

I think though that you might be underestimating the amount of
commonality. For instance, we might need a projecting node on top of
a subquery-in-FROM subplan, but that node would still have to bear
a relid --- the relid of the RTE_SUBQUERY RTE in the upper query,
not that of any RTE in the subquery, but nonetheless it's a relid.

Another variant of this is that that RTE_SUBQUERY relid would normally
be borne by a SubqueryScan plan node, but if we elide the SubqueryScan
because it isn't doing anything useful, where shall we put that relid?
If we don't store it anywhere then we will not be able to reconstruct
correct join relids for the upper plan level.

regards, tom lane