From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Marko Tiikkaja" <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: wCTE: why not finish sub-updates at the end, not the beginning? |
Date: | 2011-02-25 15:46:57 |
Message-ID: | 21855.1298648817@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Given that we've decided to run the modifying sub-queries all with
>> the same command counter ID, they are logically executing "in
>> parallel".
>> Just run the main plan and let it pull tuples from the CTEs as
>> needed.
> On the face of it, that sounds like it has another benefit you
> didn't mention -- it sounds like it's much more conducive to
> allowing parallel processing, if (when?) we eventually move in that
> direction. It might even be a good case for an initial, limited
> implementation.
Yeah. Most of the executor is in principle parallelizable at the
plan-node level (ignoring the obvious and severe implementation
problems with parallelizing *anything* in the backend). It's not
good for wCTE to be creating a user-visible assumption that certain
things will happen in a predefined order.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2011-02-25 16:03:46 | Re: wCTE: why not finish sub-updates at the end, not the beginning? |
Previous Message | Yeb Havinga | 2011-02-25 15:41:56 | Re: Sync Rep v17 |