Thomas Hallgren <[EMAIL PROTECTED]> writes:
> But if I, during the SPI_IS_FIRST_CALL phase, do an SPI_connect
> (done when the 'multi_call_memory_ctx' is current), then the leak seem
> to occur immediately. Will that connect somehow alter the durability for
> the context that is current on each
On Wed, Mar 22, 2006 at 09:09:34PM +0100, Thomas Hallgren wrote:
> There's one thing that's still a bit fuzzy to me. If I don't use SPI,
> the context that is current when my SRF function is called seems to be
> reset between each call. I can palloc stuff in it as much as I like. I
> can even cr
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
Recursive calls works in PL/Java. No problem there. But the larger the
set, the more memory it consumes. Do I read your answers correctly if I
conclude this is a known limitation when SPI is used? I.e. there's no
way to stream one
Thomas Hallgren wrote:
Recursive calls works in PL/Java. No problem there. But the larger the
set, the more memory it consumes. Do I read your answers correctly if
I conclude this is a known limitation when SPI is used? I.e. there's
no way to stream one row at a time without ever building the
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Recursive calls works in PL/Java. No problem there. But the larger the
> set, the more memory it consumes. Do I read your answers correctly if I
> conclude this is a known limitation when SPI is used? I.e. there's no
> way to stream one row at a time
Thomas Hallgren wrote:
> Recursive calls works in PL/Java. No problem there. But the larger the
> set, the more memory it consumes. Do I read your answers correctly if I
> conclude this is a known limitation when SPI is used? I.e. there's no
> way to stream one row at a time without ever buildin
Recursive calls works in PL/Java. No problem there. But the larger the
set, the more memory it consumes. Do I read your answers correctly if I
conclude this is a known limitation when SPI is used? I.e. there's no
way to stream one row at a time without ever building the full set?
Regards,
Thom
Tom Lane wrote:
plpgsql and similar languages will return a tuplestore anyway, so it has
to handle that case, and it was convenient to make all the cases look
alike for starters. Nobody's yet gone back to improve it for the case
of languages that return a tuple per call.
This would be
Martijn van Oosterhout writes:
> I think you're running into a small limitation of set functions here.
> If you look at nodeFunctionScan.c that handles this, you can see that
> the code is written in such a way as to collect all the tuples first
> before returning anything.
I don't think Thomas i
On Wed, Mar 22, 2006 at 03:31:59PM +0100, Thomas Hallgren wrote:
> Imagine the following scenario:
>
> Function 'A' returns SETOF 'x'. It will issue a query using SPI that
> calls function 'B'. This function returns SETOF 'y'.
> Each tuple of 'x' is formed from some data in 'y'.
> There will be m
Imagine the following scenario:
Function 'A' returns SETOF 'x'. It will issue a query using SPI that
calls function 'B'. This function returns SETOF 'y'.
Each tuple of 'x' is formed from some data in 'y'.
There will be millions of tuples so building a set of 'y' in memory is
not an option.
W
11 matches
Mail list logo
