On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
Sorry it's not relevant to the topic you post but ..
Relevant enough :-)
.. it seems you're going to add new executor node called DtScanNode and let it hold tuplestore passed by the Query indicated by index number. However, I suppose there are other ways: 1. Use MaterialNode instead of adding DtScanNode. Since MaterialNode is exsiting one that work with single tuplestore, it might be sane to modify this so that it accepts tuplestore from Query instead of its child node.
I thought about this, but I don't necessarily like the idea of overloading executor nodes.
2. Use temp table instead of tuplestore list. Since we agreed we need to execute each plan one by one starting and shutting down executor, it now looks very simple strategy.
I didn't look at this because I thought using a "tuplestore receiver" in the portal logic was simple enough. Any thoughts on how this would work?
I'm not familiar with the long discussion on this feature so not sure they are possible, but ISTM they are enough to be discussed (or discussed already?).
We haven't discussed this part of the design yet.. Now is a good time to do it.
Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
