Re: DELETE takes too much memory

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Kouber Saparev <kouber(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: DELETE takes too much memory
Date: 2016-07-19 14:28:20
Message-ID: 480fcd0d-f12e-c0fc-4caa-6738eeb1fce6@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message trafdev 2016-07-19 14:28:38 Re: less than 2 sec for response - possible?
Previous Message Jim Nasby 2016-07-19 14:10:57 Re: less than 2 sec for response - possible?