Re: wCTE: why not finish sub-updates at the end, not the beginning?
От | David Fetter |
---|---|
Тема | Re: wCTE: why not finish sub-updates at the end, not the beginning? |
Дата | |
Msg-id | 20110226024601.GA27388@fetter.org обсуждение исходный текст |
Ответ на | wCTE: why not finish sub-updates at the end, not the beginning? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: wCTE: why not finish sub-updates at the end, not the beginning?
|
Список | pgsql-hackers |
On Fri, Feb 25, 2011 at 09:58:36AM -0500, Tom Lane wrote: > I had what seems to me a remarkably good idea, though maybe someone else > can spot a problem with it. Given that we've decided to run the > modifying sub-queries all with the same command counter ID, they are > logically executing "in parallel". The current implementation takes no > advantage of that fact, though: it's based around the idea of running > the updates strictly sequentially. I think we should change it so that > the updates happen physically, not only logically, concurrently. > 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.) What's the effect, if any, on CTEs that depend on each other explicitly? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
В списке pgsql-hackers по дате отправления: