From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: wCTE behaviour |
Date: | 2010-11-11 19:07:11 |
Message-ID: | AANLkTinDFtoqoRuAF33qcfq3KNz5kja=jtLoRLcFYu-c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 11, 2010 at 1:53 PM, David Fetter <david(at)fetter(dot)org> wrote:
> On Thu, Nov 11, 2010 at 12:36:38PM -0500, Merlin Moncure wrote:
>> On Thu, Nov 11, 2010 at 12:13 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > then the conclusion is foregone. To my mind, they should be thought of
>> > as running in parallel, or at least in an indeterminate order, just
>> > exactly the same way that different data modifications made in a single
>> > INSERT/UPDATE/DELETE command are considered to be made simultaneously.
>>
>> +1
>
> -1.
>
> When people want to see what has gone before, they can use RETURNING
> clauses. With the "indeterminate order" proposal, they cannot.
If you want to see what happened 'before' you *must* use a returning
clause. It's the link that pipelines data from one query to another.
There is in fact no 'before', just a way to define hook output into
input. ISTM you have a lot more available routes of CTE optimization
if you go this way.
but, can you present an example of a case that depends on execution
order w/o returning? maybe I'm not seeing something...
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-11 19:13:24 | Re: wCTE behaviour |
Previous Message | Tom Lane | 2010-11-11 19:03:42 | Re: wCTE behaviour |