Re: Status report on writeable CTEs
От | Merlin Moncure |
---|---|
Тема | Re: Status report on writeable CTEs |
Дата | |
Msg-id | AANLkTilEo_-azVLdyXZLim5PcxjbQNpB0GLP9hHv90A0@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Status report on writeable CTEs (Hitoshi Harada <umi.tanuki@gmail.com>) |
Ответы |
Re: Status report on writeable CTEs
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: