Re: Changed SRF in targetlist handling
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Joe Conway <mail@joeconway.com>, Merlin Moncure <mmoncure@gmail.com>, David Fetter <david@fetter.org>, Andres Freund <andres@anarazel.de>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-05-23T21:37:06Z
Lists: pgsql-hackers
On Mon, May 23, 2016 at 4:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "David G. Johnston" <david.g.johnston@gmail.com> writes: > > On Mon, May 23, 2016 at 4:24 PM, Alvaro Herrera < > alvherre@2ndquadrant.com> > > wrote: > >> Ah, so that's what "pipeline results" mean! I hadn't gotten that. I > >> agree; Abhijit had a patch or a plan for this, a long time ago ... > > > Is this sidebar strictly an implementation detail, not user visible? > > Hmm. It could be visible in the sense that the execution of multiple > functions in one ROWS FROM() construct could be interleaved, while > (I think) the current implementation runs each one to completion > serially. But if you're writing code that assumes that, I think you > should not be very surprised when we break it. In any case, that > would not affect the proposed translation for SRFs-in-tlist, since > those have that behavior today. > Thanks Sounds like "zipper results" would be a better term for it...but, yes, if that's the general context it falls into implementation from my perspective. But then I don't get Joe's point - if its an implementation detail why should it matter if rewriting the SRF-in-tlist to be laterals changes execution from a serial to an interleaved implementation. Plus, Joe's claim: "the capability to pipeline results is still only available in the target list", and yours above are at odds since you claim the rewritten behavior is the same today. Is there a disconnect in knowledge or are you talking about different things? David J.
Commits
-
Remove obsoleted code relating to targetlist SRF evaluation.
- ea15e18677fc 10.0 landed
-
Doc: improve documentation of new SRF-in-tlist behavior.
- f13a1277aa2d 10.0 landed
-
Move targetlist SRF handling from expression evaluation to new executor node.
- 69f4b9c85f16 10.0 landed
-
Don't split up SRFs when choosing to postpone SELECT output expressions.
- d543170f2fdd 9.6.0 cited