Kyotaro HORIGUCHI <horiguchi.kyot...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers