Hello, thanks for the information and the link!
Ales čt 4. 8. 2022 v 1:05 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal: > =?UTF-8?B?QWxlxaEgWmVsZW7DvQ==?= <zeleny.a...@gmail.com> writes: > > CREATE OR REPLACE FUNCTION tescase (_id_data_provider integer, > _external_id > > bigint DEFAULT NULL::bigint, _external_complete_id character varying > > DEFAULT NULL::character varying) > > RETURNS TABLE(id_gm bigint, id_opp bigint, id_opp_state integer) > > LANGUAGE sql > > AS $function$ > > SELECT ... simple join of two tables... > > WHERE opd.id_data_provider = _id_data_provider > > AND CASE WHEN _external_id IS NULL > > THEN external_id IS NULL > > ELSE external_id = _external_id > > END > > AND CASE WHEN _external_complete_id IS NULL > > THEN _external_complete_id IS NULL > > ELSE external_complete_id = _external_complete_id > > END; > > $function$ > > ; > > > It is a kind of creative construct for me, but it works. The key here is > > that if I replace at least one of the "CASEd" where conditions, it seems > > not to suffer from the memory leak issue. > > > Finally, I've found, that even having the function as is and before the > > test disabling JIT (SET jit = off;) and calling the function 100k times, > > RssAnon memory for the given process is stable and only 3612 kB, while > when > > JIT is enabled (the default setting on the server suffering from the > memory > > leak, RssAnon memory for the given process growth in a linear manner over > > time (canceled when it reached 5GB). > > Ah. I bet this is another instance of the known memory leakage problems > with JIT inlining [1]. Per Andres' comments in that thread, it seems > hard to solve properly. For now all I can recommend is to disable that. > > regards, tom lane > > [1] > https://www.postgresql.org/message-id/flat/20201001021609.GC8476%40telsasoft.com >
