Re: reindex/vacuum locking/performance?

From: Christopher Browne <cbbrowne(at)libertyrms(dot)info>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: reindex/vacuum locking/performance?
Date: 2003-10-03 21:34:14
Message-ID: 60d6de9fah.fsf@dev6.int.libertyrms.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

nagler(at)bivio(dot)biz (Rob Nagler) 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. 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.

VACUUM FULL certainly does lock.

See the man page:

INPUTS
FULL Selects ``full'' vacuum, which may reclaim more space, but takes
much longer and exclusively locks the table.

The usual answer is that you probably _didn't_ want to VACUUM FULL.

VACUUM ('no full') does NOT block updates.

> The same thing seemed to be happening with reindex on a table. It
> seems that the reindex locks the table and some other resource which
> then causes deadlock with other active processes.

Not surprising either. While the reindex takes place, updates to that
table have to be deferred.

> 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).

That seems a little surprising.

> 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?

Consider running pg_autovacuum, and thereby do a little bit of
vacuuming here and there all the time. It DOESN'T block, so unless
your system is really busy, it shouldn't slow things down to a major
degree.
--
"cbbrowne","@","libertyrms.info"
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2003-10-03 21:35:46 Re: Speeding up Aggregates
Previous Message Dror Matalon 2003-10-03 21:28:48 Re: Speeding up Aggregates