Hello, Thank you for suggestions. > > 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.
Hmm.. Concerning tuple-lifespan, almost every types of node which may do projection has the route for no-projInfo. This patch for nodeResult eventually does the same thing. If they are special cases and the operation could not be done generally, I should follow the real(or hidden amoung code lines?) lifespan regulation... >From the another point of view, execution nodes may hold tupleslots which palloc'ed in projInfos of them just after receiving a result tuple from their childs. And thy are finally free'd in next projection on the same node or ExecEndNode() after the fiish of processing the entire current query. The life of the contents in the slots should be valid until next projection in upper nodes or sending the result tuple. The execution tree is bottom-spreaded and every node in it could not be executed under different ancestors, and no multi-threaded execution.. The above is the figure from my view. And I suppose these facts(is it correct?) are enough to ensure the tuple-lifeplan. And concerning genericity of 'identity projection', .. Perhaps you're right. I capsulated the logic into ExecProject but it is usable only from a few kind of nodes.. I'll revert modification on ExecProject and do identity projection on each nodes which can do that. > 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. I completely agree with the last sentence regarding Result node. As I described in the previous message, it was a bit hard to find the way to do that. I'll seek for that with more effort. > 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. The whole table is on memory and query is very simple and the number of columns is relatively larger in this case. This is because I intended to improve retrieving a large part of partitioned table with many columns. In this case, the executor shuttles up and down in shallow tree and every level does almost nothing, but the result node does pfree/palloc and direct mapping up to 30 columns which seems rather heavy in the whole this execution. I could found no sign of failure of optimization in that so simple execution tree... And the effect of cource becomes smaller for fewer columns or more complex queries, or queries on tables hanging out of memory onto disks. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
