From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: wCTE: about the name of the feature |
Date: | 2011-02-26 05:30:25 |
Message-ID: | 7653.1298698225@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Yay! I'm excited about this, particularly the possible "pipelining"
> stuff, where you can do WITH (DELETE .. RETURNING ..) INSERT ... and
> have it be like cool and fast and stuff.
> Or at least I hope you can do that.
It's gonna need some work yet. As things stand, the tuples are indeed
pipelined through, but the CteScan nodes *also* stash them aside into
tuplestores, just in case somebody demands a rescan. Fixing that will
require revisiting the exec flags (EXEC_FLAG_REWIND etc). We don't
currently distinguish "it's unlikely you'll have to rescan" from
"you're guaranteed not to have to rescan", but a CteScan that's covering
a ModifyTable has to know the latter to not have to keep hold of copies
of the RETURNING tuples.
It might be a small enough change to do after alpha starts, but I don't
have time for it right now.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-02-26 05:52:40 | Re: wCTE: about the name of the feature |
Previous Message | Robert Haas | 2011-02-26 05:29:14 | Re: WIP: cross column correlation ... |