Re: reindex/vacuum locking/performance?

nagler@bivio.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)