Thread: SRF optimization question

I am writing a set returning function in C.  There are cases where I can
know definitively, upfront, that this function will only return one row.
I have noticed, through happenstance of partially converted function, that
I can mark a normal, non-set returning function as returning SETOF
something, while not utilizing the SRF macros and using PG_RETURN_DATUM,
and it still works as returning one row.

I am wondering, if it is an acceptable optimization that if I know
up-front that a function will only return one row, to avoid all of the
SRF overhead of setting up a new memory context, and a function context
struct, and requiring an extra call to my function to tell Postgres that I
am done sending rows, to simply not use the SRF stuff and interact with
Postgres as though I was not returning SETOF?  Is this a sane idea, or did
I just stumble into an accidental feature when I changed my CREATE
FUNCTION statement without changing my C code?



-- 
UNIX was half a billion (500000000) seconds old on
Tue Nov  5 00:53:20 1985 GMT (measuring since the time(2) epoch).    -- Andy Tannenbaum

On Sat, 2007-02-03 at 15:51 -0800, Jeremy Drake wrote:
> I am writing a set returning function in C.  There are cases where I can
> know definitively, upfront, that this function will only return one row.
> I have noticed, through happenstance of partially converted function, that
> I can mark a normal, non-set returning function as returning SETOF
> something, while not utilizing the SRF macros and using PG_RETURN_DATUM,
> and it still works as returning one row.
> 
> I am wondering, if it is an acceptable optimization that if I know
> up-front that a function will only return one row, to avoid all of the
> SRF overhead of setting up a new memory context, and a function context
> struct, and requiring an extra call to my function to tell Postgres that I
> am done sending rows, to simply not use the SRF stuff and interact with
> Postgres as though I was not returning SETOF?  Is this a sane idea, or did
> I just stumble into an accidental feature when I changed my CREATE
> FUNCTION statement without changing my C code?

Well, I'd say its either an SRF or its not. If you want to do 
select * from myfunc(), then it has to be an SRF. 

You *can* have a function that returns a composite type, but that is
executed in a slightly different manner.
e.g. select myfunc() from oneRowTable;

Either way you have the overhead of the scan, so I see no optimization
by trying to remove the SRF stuff.

So I think you've found a minor bug, not a feature. But how do we check
for SRF macros? With difficulty or overhead, one of the two.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com