On 2010-11-07 8:08 PM +0200, Tom Lane wrote:
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?
The immediate problem at hand was that scan nodes cached the number of
blocks a relation has and didn't see new tuples added by wCTEs. That's
not unfixable, but the consensus seemed to be that running the executor
separately is better.
ModifyTable nodes still save us from duplicating a lot of code; you can
just run an executor on a plan and expect it to work, even it's a DML
statement. Reverting it would be a huge mistake in my opinion.
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
