SRF in SFRM_ValuePerCall mode - Mailing list pgsql-hackers

From dv @ nabble
Subject SRF in SFRM_ValuePerCall mode
Date
Msg-id E7965A588AB945FBA7F86292D1D0DF11@dvhome
Whole thread Raw
Responses Re: SRF in SFRM_ValuePerCall mode  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List pgsql-hackers
Hi all,

I am working on implementation of custom "C" SRF for our team. The SRF uses
SFRM_ValuePerCall mode. I know that sometimes even in SFRM_ValuePerCall mode
all the rows returned from SRF are "materialized" (for performing JOINs, for
example). But it looks like even in cases when SELECT is very simple and
it's obvious that no more rows will be read from the SRF, SRF is being
iterated till it returns SRF_RETURN_DONE(...). So, in case when the SRF
returns 1000 rows but the SELECT is querying only the first one (with LIMIT
1), all 1000 iterations will be performed and 999 rows will be created,
allocated, returned and thrown away.

Is there a way to avoid unnecessary calls of SRF in this case? Is it a
"feature"?

In the attachment you can find the simplest example of SRF function working
in SFRM_ValuePerCall mode.
I have created it while researching the issue. After building it, use the
following SQLs:

--  this creates the test function
CREATE OR REPLACE FUNCTION vpc() RETURNS setof record
    AS 'plbsh.dll', 'vpc' LANGUAGE 'C';

--  this returns 10 rows
SELECT * FROM vpc() AS T(a INT, b TEXT);

--  this returns 1 row, but performs 10 calls
SELECT * FROM vpc() AS T(a INT, b TEXT) LIMIT 1;

Regards,
Denis

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: MERGE Specification
Next
From: "Heikki Linnakangas"
Date:
Subject: Re: SRF in SFRM_ValuePerCall mode