2010/11/8 Tom Lane <t...@sss.pgh.pa.us>: > Marko Tiikkaja <marko.tiikk...@cs.helsinki.fi> writes: >> On 2010-11-07 6:23 PM +0200, Tom Lane wrote: >>> Um ... why? I thought the whole point of breaking out ModifyTable >>> as a separate node type was so that a query involving writeable CTEs >>> would still be just one plan tree. > >> We tried that for 9.0 and it didn't work. Almost all work for 9.1 has >> been spent on creating an infrastructure for running the executor >> separately for every WITH list element when wCTEs are present. > > I guess I shoulda been paying closer attention :-(. That really, really > seems like fundamentally the wrong direction. What was it that was > unfixable about the other way? If it is unfixable, should we revert > ModifyTable?
Especially snapshot should not be updated during execution so we decided to separate plans and restart executor. But reading closer your response, it occurred to me that ModifyTable can be the storage to be shared among separated plans instead of newly invented DtScan. Are you suggesting embed ModifyTable into the main query, that is also on the top of child plans? In this way we can still separate plans and scan the result of child plans without much modification of portal/explain? Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
