Re: reindex/vacuum locking/performance?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rob Nagler <nagler(at)bivio(dot)biz>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: reindex/vacuum locking/performance?
Date: 2003-10-03 20:57:56
Message-ID: 954.1065214676@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Rob Nagler <nagler(at)bivio(dot)biz> writes:
> I've read some posts that says vacuum doesn't lock, but my experience
> today indicates the opposite. It seemed that "vacuum full analyze"
> was locked waiting and so were other postmaster processes.

vacuum full does require exclusive lock, plain vacuum does not.

> It
> appeared to be deadlock, because all were in "WAITING" state according
> to ps. I let this go for about a 1/2 hour, and then killed the vacuum
> at which point all other processes completed normally.

It's considerably more likely that the vacuum was waiting for an open
client transaction (that had a read or write lock on some table) to
finish than that there was an undetected deadlock. I suggest looking at
your client code. Also, in 7.3 or later you could look at the pg_locks
view to work out exactly who has the lock that's blocking vacuum.

> Another issue seems to be performance. A reindex on some indexes is
> taking 12 minutes or so. Vacuum seems to be slow, too. Way longer
> than the time it takes to reimport the entire database (30 mins).

vacuum full is indeed slow. That's why we do not recommend it as a
routine maintenance procedure. The better approach is to do plain
vacuums often enough that you don't need vacuum full. In pre-7.4
releases you might need periodic reindexes too, depending on whether
your usage patterns tickle the index-bloat problem. But it is easily
demonstrable that reindexing is cheaper than rebuilding the database.

> In summary, I suspect that it is better from a UI perspective to bring
> down the app on Sat at 3 a.m and reimport with a fixed time period
> than to live through reindexing/vacuuming which may deadlock. Am I
> missing something?

Almost certainly, though you've not provided enough detail to determine
what.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2003-10-03 21:07:10 Re: Speeding up Aggregates
Previous Message Ron Johnson 2003-10-03 20:42:32 Re: [PERFORM] Postgres low end processing.