From: | Kouber Saparev <kouber(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: DELETE takes too much memory |
Date: | 2016-07-07 07:39:59 |
Message-ID: | CAN4RuQsEnK-A3zHKPyjgPQ1W73ku0WSu52idy4hH3k1-1x4M3g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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 |
Modifiers
-------------------+-----------------------------+-----------------------------------------------------------------------
id | bigint | not null default
nextval('audits.audits_id_seq'::regclass)
auditable_type_id | oid | not null
auditable_id | integer |
operation | audits.operation | not null
old_data | jsonb |
new_data | jsonb |
user_id | integer | default
(NULLIF(session.get_var('user_id'::text), ''::text))::integer
ip | inet | default
(NULLIF(session.get_var('ip'::text), ''::text))::inet
service_name | character varying(100) | default
NULLIF(session.get_var('service'::text), ''::text)
service_action | text | default
NULLIF(session.get_var('action'::text), ''::text)
created_at | timestamp without time zone | not null default
clock_timestamp()
Indexes:
"audits_pkey" PRIMARY KEY, btree (id)
"index_audits_on_auditable_type_id_and_auditable_id" btree
(auditable_type_id, auditable_id)
"index_audits_on_created_at" btree (created_at)
2016-07-06 19:12 GMT+03:00 Merlin Moncure <mmoncure(at)gmail(dot)com>:
> On Mon, Jul 4, 2016 at 11:35 AM, Kouber Saparev <kouber(at)gmail(dot)com> 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 to other
> > tables, nor other tables refer to it. The size of the table itself is 19
> GB
> > (15% of 120 GB). So why the DELETE tried to put the entire table in
> memory,
> > or what did it do to take so much memory?
> >
> > I am using 9.4.5.
>
> How did you measure memory usage exactly? In particular, memory
> consumption from the pid attached to the query or generalized to the
> server? Is this linux and if so what memory metric did you use? What
> kinds of indexes are on this table (in particular, gin/gist?)?
>
> merlin
>
From | Date | Subject | |
---|---|---|---|
Next Message | Kaixi Luo | 2016-07-07 07:49:58 | Re: Tuning guidelines for server with 256GB of RAM and SSDs? |
Previous Message | Mark Kirkwood | 2016-07-07 04:59:46 | Re: Tuning guidelines for server with 256GB of RAM and SSDs? |