| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Changed SRF in targetlist handling |
| Date: | 2016-05-23 21:58:51 |
| Message-ID: | 57437D1B.7040502@joeconway.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 05/23/2016 02:37 PM, David G. Johnston wrote:
> 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?
Unless there have been recent changes which I missed, ValuePerCall SRFs
are still run to completion in one go, when executed in the FROM clause,
but they project one-row-at-a-time in the target list. If your SRF
returns many-many rows, the problem with the former case is that the
entire thing has to be materialized in memory.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-05-23 22:05:39 | Re: Inheritance |
| Previous Message | Tom Lane | 2016-05-23 21:53:37 | Re: Re: [BUGS] BUG #14153: Unrecognized node type error when upsert is present in recursive CTE |