Re: The flinfo->fn_extra question, from me this time. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: The flinfo->fn_extra question, from me this time.
Date
Msg-id 20930.1569164512@sss.pgh.pa.us
Whole thread Raw
In response to Re: The flinfo->fn_extra question, from me this time.  (Dent John <denty@QQdd.eu>)
Responses Re: The flinfo->fn_extra question, from me this time.
List pgsql-hackers
Dent John <denty@QQdd.eu> writes:
> On 21 Jul 2019, at 22:54, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Chapman Flack <chap@anastigmatix.net> writes:
>>> But looking in the code, I'm getting the impression that those
>>> benefits are only theoretical future ones, as ExecMakeTableFunctionResult
>>> implements SFRM_ValuePerCall mode by ... repeatedly calling the function
>>> to build up a whole tuplestore in advance.

>> Yes, that's the case for a SRF in FROM.  A SRF in the targetlist
>> actually does get the chance to pipeline, if it implements ValuePerCall.
>> The FROM case could be improved perhaps, if somebody wanted to put
>> time into it.

> By any chance, do either of you know if there are initiatives to make the changes mentioned?

I don't know of anybody working on it.

>> You'd still need to be prepared to build a tuplestore,
>> in case of rescan or backwards fetch; but […]

> I’m also interested in your comment here. If the function was STABLE, could not the function scan simply be
restarted?(Rather than needing to create the tuplestore for all cases.) 
> I guess perhaps the backwards scan is where it falls down though...

My point was that you can't simply remove the tuplestore-building code
path.  The exact boundary conditions for that might be negotiable.
But I'd be very dubious of an assumption that re-running the function
would be cheaper than building a tuplestore, regardless of whether it's
safe.

> Does the planner have any view on this?

cost_functionscan and cost_rescan would likely need some adjustment if
possible.  However, I'm not sure that the planner has any way to know
whether a given SRF will support ValuePerCall or not.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: Index Skip Scan
Next
From: Jeff Janes
Date:
Subject: Re: WAL recycled despite logical replication slot