Consider this test case:
create table baz (a int, b int);
insert into baz (select 1, generate_series(1, 300));
select baz.*, (select 1 from generate_series(1, 1) g(a)
where g.a baz.b)
from baz;
The final query consumes ~800 MB of memory on my
Neil Conway [EMAIL PROTECTED] writes:
Two different classes of allocations in the EState's per-query context
are leaked:
(1) In FunctionNext(), we call ExecMakeTableFunctionResult() to compute
the result set of the SRF, which allocates the TupleDesc out-parameter
in the per-query memory
Neil Conway [EMAIL PROTECTED] writes:
On Thu, 2008-02-21 at 21:42 -0500, Tom Lane wrote:
Yeah. I think it's hopeless to expect these functions to all hew to
the straight and narrow path. It seems to me that the right way is for
the sub-select to somehow run in its own per-query context.
On Thu, 2008-02-21 at 21:42 -0500, Tom Lane wrote:
Given your point (2), is this worth fixing by itself?
Right, probably not.
Yeah. I think it's hopeless to expect these functions to all hew to
the straight and narrow path. It seems to me that the right way is for
the sub-select to somehow
