Prev: On a somewhat disappointing correspondence
Next: [HACKERS] Partitioning/inherited tables vs FKs
From: Nikhil Sontakke on 8 May 2010 00:06
>> Yeah this is my basic confusion. But wouldn't the arguments be
>> evaluated afresh on the subsequent call for this SRF?
>
> No, see ExecMakeFunctionResult().  If we did that we'd have serious
> problems with volatile functions, ie srf(random()).
>

Ok thanks. So if someone uses a really long-running srf with argument
expression evaluations thrown in, then running into "out of memory"
issues should be expected and then in those cases they are better off
using multiple srf calls to get the same effect if they can..

Regards,
Nikhils
--
http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 8 May 2010 10:01
Nikhil Sontakke <nikhil.sontakke(a)enterprisedb.com> writes:
> Ok thanks. So if someone uses a really long-running srf with argument
> expression evaluations thrown in, then running into "out of memory"
> issues should be expected and then in those cases they are better off
> using multiple srf calls to get the same effect if they can..

I believe this is only an issue for SRFs called in a query targetlist,
which is a usage fraught with semantic problems anyway. Hopefully we
can get LATERAL done soon (I'm planning to look at it for 9.1) and
then deprecate this whole mess.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Joe Conway on 8 May 2010 11:17
On 05/07/2010 09:06 PM, Nikhil Sontakke wrote:
>>> Yeah this is my basic confusion. But wouldn't the arguments be
>>> evaluated afresh on the subsequent call for this SRF?
>>
>> No, see ExecMakeFunctionResult(). If we did that we'd have serious
>> problems with volatile functions, ie srf(random()).
>
> Ok thanks. So if someone uses a really long-running srf with argument
> expression evaluations thrown in, then running into "out of memory"
> issues should be expected and then in those cases they are better off
> using multiple srf calls to get the same effect if they can..

I've very recently looked into this exact case myself for someone, and
came to the conclusion that there is no simple fix for this. If you want
to see a concrete example of a query that fails, apply your patch and
then run the regression tests -- the "misc" test will fail.

I think this is an example of why we still need to implement a real
SFRM_ValuePerCall mode that allows results to be pipelined. Yes,
ValuePerCall sort of works from the targetlist, but it is pretty much
useless for the use cases where people really want to use it.

Or would a FROM clause ValuePerCall suffer the same issue?

Joe


From: Tom Lane on 8 May 2010 12:12
Joe Conway <mail(a)joeconway.com> writes:
> I think this is an example of why we still need to implement a real
> SFRM_ValuePerCall mode that allows results to be pipelined. Yes,
> ValuePerCall sort of works from the targetlist, but it is pretty much
> useless for the use cases where people really want to use it.

> Or would a FROM clause ValuePerCall suffer the same issue?

I don't think it'd be a big problem. We could use the technique
suggested in the comments in ExecMakeTableFunctionResult: use a separate
memory context for evaluating the arguments than for evaluating the
function itself. This will work in FROM because we can insist the SRF
be at top level. The problem with SRFs in tlists is that they can be
anywhere and there can be more than one, so it's too hard to keep track
of what to reset when.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Joe Conway on 8 May 2010 12:44
On 05/08/2010 09:12 AM, Tom Lane wrote:
> Joe Conway <mail(a)joeconway.com> writes:
>> I think this is an example of why we still need to implement a real
>> SFRM_ValuePerCall mode that allows results to be pipelined. Yes,
>> ValuePerCall sort of works from the targetlist, but it is pretty much
>> useless for the use cases where people really want to use it.
>
>> Or would a FROM clause ValuePerCall suffer the same issue?
>
> I don't think it'd be a big problem. We could use the technique
> suggested in the comments in ExecMakeTableFunctionResult: use a separate
> memory context for evaluating the arguments than for evaluating the
> function itself. This will work in FROM because we can insist the SRF
> be at top level. The problem with SRFs in tlists is that they can be
> anywhere and there can be more than one, so it's too hard to keep track
> of what to reset when.

That's what I was thinking. I saw your other email about LATERAL for 9.1
-- would it be helpful for me to work on this issue for 9.1? After all,
about 7 years ago I said I'd do it ;-). Or do you think it will be an
integral part of the LATERAL work?

Joe


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: On a somewhat disappointing correspondence
Next: [HACKERS] Partitioning/inherited tables vs FKs