On 7/5/16 4:03 PM, Kouber Saparev wrote:
Could such a memory consumption be related to a GET DIAGNOSTICS plpgsql block? The delete itself is within a stored procedure, and then I return the amount of the deleted rows from the function:
Looking at the code, no, GET DIAG won't change anything; exec_stmt_execsql() is simply remembering the count returned by SPI; it has no idea whether anything will end up using that count.
The only thing I can think of is that you have triggers that are consuming the memory (either the trigger funcs, or because it's an after/constraint trigger), or that there's something screwy with finding the target rows. I can't see how the latter could be an issue if id is a simple int though.
There are ways to get memory debug info, but I'm not sure if they'd really be safe to use in production (in particular, they require stopping the process by attaching gdb and calling a function. I think you also need a special compile.)
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
