On Fri, Jul 16, 2010 at 12:15 PM, Hitoshi Harada <umi.tan...@gmail.com> wrote: > 2010/7/17 Marko Tiikkaja <marko.tiikk...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers