On Fri, Jul 16, 2010 at 12:15 PM, Hitoshi Harada <umi.tanuki@gmail.com> wrote:
> 2010/7/17 Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>:
>> On 7/16/10 6:15 PM +0300, Hitoshi Harada wrote:
>>>
>>> 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.
>
> Neither do I have good shape for this solution. Maybe it's not good
> idea. But my concern is adding DtScanNode, which looks similar to
> MaterialNode. Of course each purpose is different, but quite big part
> will overlap each other, I think.
>
>>> 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?
>
> It's just deconstructing queries like:
>
> WITH t AS (INSERT INTO x ... RETURING *)
> SELECT * FROM t;
>
> to
>
> CREATE TEMP TABLE t AS INSERT INTO x ... RETURING *;
> SELECT * FROM t;
Is it acceptable for a wCTE query to manipulate the system catalogs?
Couldn't this cause performance issues in some cases?
merlin