Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> This patch reduces run time of such queries by 45% when result
> recored has 30 columns and seems to have no harm for performance.
This patch seems quite unsafe to me: it's not generally okay for
a plan node to return a slot that doesn't belong to it, because of
tuple-lifespan issues. It's possible that Result in particular
could do that safely, but if so we ought to hack nodeResult.c for
it, not the generic projection machinery.
Something I'd been considering in connection with another example
is teaching the planner not to generate a Result node in the first
place, if the node is just doing an identity projection. There
are a couple of ways that could be done --- one is to get setrefs.c
to remove the node on-the-fly, similar to what it does with
SubqueryScan. But it might be better just to check whether the
node is actually needed before creating it in the first place.
Another point here is that the projection code already special-cases
simple projections, so it's a bit hard to believe that it's as slow as
you suggest above. I wonder if your test case is confusing that
optimization somehow.
regards, tom lane
