Re: reindex/vacuum locking/performance? - Mailing list pgsql-performance

From Matt Clark
Subject Re: reindex/vacuum locking/performance?
Date
Msg-id LFEIJBEOKGPDHCEMDGNFMEOBCFAA.matt@ymogen.net
Whole thread Raw
In response to Re: reindex/vacuum locking/performance?  (Rob Nagler <nagler@bivio.biz>)
Responses Re: reindex/vacuum locking/performance?
List pgsql-performance
> > vacuum full does require exclusive lock, plain vacuum does not.
>
> I think I need full, because there are updates on the table.  As I
> understand it, an update in pg is an insert/delete, so it needs
> to be garbage collected.

Yes and no.  You only need a plain VACUUM that is run often enough to
recover space as fast as you need to grab it.  For heavily updated tables
run it often - I run it every 5 minutes on some tables.  A VACUUM FULL is
only needed if you haven't been running VACUUM often enough in the first
place.

> The description of vacuum full implies that is required if the db
> is updated frequently.   This db gets about 1 txn a second, possibly
> more at peak load.

Assuming you mean 1 update/insert per second that is an absolutely _trivial_
load on any reasonable hardware.  You can do thousands of updates/second on
hardware costing less than $2000.  If you vacuum every hour then you will be
fine.

> IOW, vacuum+reindex is faster than dump+restore?  I didn't see this,
> then again, I had this locking problem, so the stats are distorted.

REINDEX also locks tables like VACUUM FULL.  Either is terribly slow, but
unless you turn off fsync during the restore it's unlikely to be slower than
dump & restore.

Matt


pgsql-performance by date:

Previous
From: Christopher Browne
Date:
Subject: Re: reindex/vacuum locking/performance?
Next
From: Josh Berkus
Date:
Subject: Re: reindex/vacuum locking/performance?