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 | 20171007003654.l7yzevzlcemczzlz@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
|
Список | pgsql-bugs |
On 2017-10-06 20:28:21 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > 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? > > I think that's basically a dead-end solution. It amounts to saying > that no functions can leak memory, which is not a place we're ever > likely to get to, especially given that there's been no policy > favoring that in the past (with the narrow exception of btree > comparison functions). Hm. We've a bunch of places where we free detoasted data, just out of efficiency concerns. And since the jsonb functions are quite likely to detoast a lot, it doesn't seem unreasonable to do so for the most likely offenders. I mean if you've a bit more complex expression involving a few fields accessed, freeing in the accesses will reduce maximum memory usage by quite a bit. I'm not suggesting to work towards leak free, just towards reducing the lifetime of a few potentially large allocations. 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 по дате отправления: