Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
Date
Msg-id CA+TgmoYoWja8V8iKb7GhT7LivydkGmuSiO6QOvaEjeU+iMKWpQ@mail.gmail.com
Whole thread Raw
In response to Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)  (Andres Freund <andres@anarazel.de>)
Responses Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
Next
From: Robert Haas
Date:
Subject: Re: autonomous transactions