Re: [BUGS] json(b)_array_elements use causes very large memory usagewhen also referencing entire json document
От | Andres Freund |
---|---|
Тема | Re: [BUGS] json(b)_array_elements use causes very large memory usagewhen also referencing entire json document |
Дата | |
Msg-id | 20171007002116.2fqr6z26byhsjwoe@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [BUGS] json(b)_array_elements use causes very large memory usage when also referencing entire json document (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] json(b)_array_elements use causes very large memory usage when also referencing entire json document
Re: [BUGS] json(b)_array_elements use causes very large memory usage when also referencing entire json document |
Список | pgsql-bugs |
On 2017-10-06 15:37:03 -0400, Tom Lane wrote: > So a leak would occur in any case ... but it's particularly awful in > this case, because data->'id' involves detoasting the rather wide > value of "data", which is then promptly leaked. While not tackling the problem in a systematic manner, it seems like it'd be a good idea to free the detoasted column in this and related functions? > As of v10, it might be possible to fix this for the tlist case > as well, by doing something like using a separate short-lived > context for the non-SRF tlist items. Yea, that should be quite doable, slightly annoying to need more than one expr context, but that seems unavoidable. Should even be doable for SFRM_ValuePerCall? SFRM_Materialize isn't a "central" problem, given it properly manages memory for the tuplestore and filling the tuplestore is an internal matter. Greetings, Andres Freund -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: