From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Jeff Davis <jdavis-pgsql(at)empires(dot)org>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: SRF in C |
Date: | 2004-01-16 22:39:55 |
Message-ID: | 4008683B.70504@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Bruce Momjian wrote:
> Jeff Davis wrote:
>>in section _37.7.1.2. RETURN NEXT_ of the docs, it says that "PL/pgSQL
>>stores the entire result set before returning from the function".
>>
>>Is the same true for C, and if so, should we document it in
>>_33.7.9. Returning Sets from C-Language Functions_ ?
>>
>>It could be important if someone wanted to return a huge amount of data
>>from an SRF and it was larger than available RAM.
>
> I would assume the C function guys would know this was obvious.
Actually, the situation is a bit more complicated. The section Jeff is
referring to is the one-row-at-a-time (SFRM_ValuePerCall) api that in
theory should not have to suffer from the mentioned limitation in
PL/pgSQL (which uses SFRM_Materialize).
However, the one-row-at-a-time ends up being accumulated into a
tuplestore by ExecMakeTableFunctionResult() anyway, effectively making
SFRM_ValuePerCall look just like SFRM_Materialize, so the memeory
efficiency benefit from SFRM_ValuePerCall is lost :-(
We had talked about supporting both modes, and it has always been on my
long-term personal TODO to go back and address this. But since the
release of 7.3 I have yet to hear a single real life case where the
current SFRM_Materialize mode has been a problem, so fixing this has
stayed low on my list.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan Bartlett | 2004-01-16 22:43:44 | Re: embedded/"serverless" (Re: serverless postgresql) |
Previous Message | Bill McMilleon | 2004-01-16 22:31:40 | Tool to ease development of plpgsql |