On Sun, Aug 28, 2016 at 3:18 AM, Andres Freund <andres@anarazel.de> wrote:
> 0003-Avoid-materializing-SRFs-in-the-FROM-list.patch
> To avoid performance regressions from moving SRFM_ValuePerCall SRFs to
> ROWS FROM, nodeFunctionscan.c needs to support not materializing
> output.
>
> In my present patch I've *ripped out* the support for materialization
> in nodeFunctionscan.c entirely. That means that rescans referencing
> volatile functions can change their behaviour (if a function is
> rescanned, without having it's parameters changed), and that native
> backward scan support is gone. I don't think that's actually an issue.
Can you expand on why you think those things aren't an issue? Because
it seems like they might be.
> 0006-Remove-unused-code-related-to-targetlist-SRFs.patch
> Now that there's no targetlist SRFs at execution time anymore, rip out
> executor and planner code related to that. There's possibly more, but
> that's what I could find in a couple passes of searching around.
>
> This actually speeds up tpch-h queries by roughly 4% for me.
Nice.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company