Skip site navigation (1) Skip section navigation (2)

Re: make bulk deletes faster?

From: James Klo <jklo(at)arkitec(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: make bulk deletes faster?
Date: 2005-12-19 08:17:06
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
In article <20051219023616(dot)GA89670(at)winnie(dot)fuhr(dot)org>,
 mike(at)fuhr(dot)org (Michael Fuhr) wrote:

> On Sat, Dec 17, 2005 at 09:10:40PM -0800, James Klo wrote:
> > I'd like some suggestions on how to get the deletes to happen faster, as 
> > while deleting individually appears to extremely fast, when I go to 
> > delete lots of rows the operation takes an extremely long time to 
> > complete (5000 rows takes about 3 minutes, 1000000 rows takes almost 
> > close to 4 hours or more depending upon server load; wall time btw).
> Those times do seem excessive -- do any other tables have foreign
> key references to the table you're deleting from?  If so, do those
> tables have indexes on the referring columns?  Does this table or
> any referring table have triggers?  Also, are you regularly vacuuming
> and analyzing your tables?  Have you examined pg_locks to see if
> an unacquired lock might be slowing things down?

As the table was originally created using Hibernate, yes, there are 
several key references, however I've already added indexes those tables 
on referring keys.  There are no triggers, we were running 
pg_autovaccum, but found that it wasn't completing.  I believe we 
disabled, and are now running a cron every 4 hours. My archiving method, 
is also running analyze - as I figure after a mass deletes, it would 
probably keep query speeds from degrading.)

I've looked at pg_locks, but not sure I understand quite how to use it 
to determine if there are unacquired locks.  I do know that we 
occasionally get some warnings from C3P0 that states it detects a 
deadlock, and allocates emergency threads.

BTW, If I didn't mention, we are using PG 8.1 on Red Hat Enterprise, 4GB 
RAM, 4 dual-core CPUs, think its RAID5 (looks like what I would consider 
typical Linux partitioning /, /tmp, /usr, /var, /boot, /home).  After 
trolling the archives, and doing a bit of sleuthing on the DB, I'm lead 
to believe that this is more or less a default install of PG 8.1. As I'm 
relatively new to PG, I'm not sure how it should be configured for our 
setup.  I would suspect that this could probably effect the speed of 
deletes (and queries as well).

Thanks for any help you can provide.

In response to

pgsql-performance by date

Next:From: Mitch SkinnerDate: 2005-12-19 10:39:31
Subject: Re: make bulk deletes faster?
Previous:From: Luke LonerganDate: 2005-12-19 07:21:07
Subject: Re: PostgreSQL and Ultrasparc T1

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group