| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f) |
| Date: | 2017-01-30 23:54:50 |
| Message-ID: | 11652.1485820490@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> Wonder if we there's an argument to be made for implementing this
> roughly similarly to split_pathtarget_at_srf - instead of injecting a
> ProjectSet node we'd add a FunctionScan node below a Result node.
Yeah, possibly. That would have the advantage of avoiding an ExecProject
step when the SRFs aren't buried, which would certainly be the expected
case.
If you don't want to make ExecInitExpr responsible, then the planner would
have to do something like split_pathtarget_at_srf anyway to decompose the
expressions, no matter which executor representation we use.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2017-01-31 00:10:02 | Re: Performance improvement for joins where outer side is unique |
| Previous Message | Peter Geoghegan | 2017-01-30 23:51:36 | Re: Subtle bug in "Simplify tape block format" commit |