On 2011-02-25 4:58 PM, Tom Lane wrote:
Specifically, I'm imagining getting rid of the patch's additions to InitPlan and ExecutePlan that find all the modifying sub-queries and force them to be cycled to completion before the main plan runs. Just run the main plan and let it pull tuples from the CTEs as needed. Then, in ExecutorEnd, cycle any unfinished ModifyTable nodes to completion before shutting down the plan. (In the event of an error, we'd never get to ExecutorEnd, but it doesn't matter since whatever updates we did apply are nullified anyhow.)
This idea has actually been discussed before when we talked about optimizing wCTEs, but IIRC you said that doing this in ExecutorEnd is a bit ugly. But if you can write this idea down in a way that makes you happy with the implementation, I think it's a huge benefit and we should definitely do it.
This has a number of immediate and future implementation benefits:
3. The code could be significantly simpler. Instead of that rather complex and fragile logic in InitPlan to try to locate all the ModifyTable nodes and their CTEScan parents, we could just have ModifyTable nodes add themselves to a list in the EState during ExecInitNode. Then ExecutorEnd just traverses that list.
Sounds good to me.
However, the real reason for doing it isn't any of those, but rather to establish the principle that the executions of the modifying sub-queries are interleaved not sequential. We're never going to be able to do any significant optimization of such queries if we have to preserve the behavior that the sub-queries execute sequentially. And I think it's inevitable that users will manage to build such an assumption into their queries if the first release with the feature behaves that way.
Yeah, you might be right. 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
