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;
e
I was using the pg_activity monitoring tool, which I find quite awesome.
https://github.com/julmon/pg_activity
There are 3 btree indexes, here's the definition of the table itself:
Table "audits.audits"
Column |Type
On Mon, Jul 4, 2016 at 11:35 AM, Kouber Saparev wrote:
> I tried to DELETE about 7 million rows at once, and the query went up to 15%
> of the RAM (120 GB in total), which pushed some indexes out and the server
> load went up to 250, so I had to kill the query.
>
> The involved table does not have
Well, basically there are only INSERTs going on there (it is a table
holding audit records for each DML statement). I do not see how a DELETE
statement could block an INSERT?
You are correct that rebuilding the table will be faster, but then, there
is a chance that some INSERT's will be blocked an
On 07/04/2016 10:10 AM, Kouber Saparev wrote:
> No. There are AFTER triggers on other tables that write to this one
> though. It is an audits table, so I omitted all the foreign keys on purpose.
Is it possible that the DELETE blocked many of those triggers due to
locking the same rows?
Incidental
No. There are AFTER triggers on other tables that write to this one though.
It is an audits table, so I omitted all the foreign keys on purpose.
2016-07-04 20:04 GMT+03:00 Alvaro Herrera :
> Kouber Saparev wrote:
> > I tried to DELETE about 7 million rows at once, and the query went up to
> > 15%
Kouber Saparev wrote:
> I tried to DELETE about 7 million rows at once, and the query went up to
> 15% of the RAM (120 GB in total), which pushed some indexes out and the
> server load went up to 250, so I had to kill the query.
>
> The involved table does not have neither foreign keys referring t
I tried to DELETE about 7 million rows at once, and the query went up to
15% of the RAM (120 GB in total), which pushed some indexes out and the
server load went up to 250, so I had to kill the query.
The involved table does not have neither foreign keys referring to other
tables, nor other tables
