"Victoria Parsons" <victoria.parsons at streamshield.com> writes:
> We have found we need to perform this vacuum full on pg_listener once
> every 10 minutes, instead of once an hour, but doing that our
> performance problem is fixed. I am a bit worried about locks, but my
> test system has now been running with the vacuum full (only on
> pg_listener) every 2 minutes for 3 days, and nothing has reported an
> error. A block causing a slight delay is much better than a constant
> performance problem.

I don't see this being a particularly "awful" application of VACUUM
FULL.

VACUUM FULL on pg_listener will cause a bit of deferral of replication
activity, but what's good is that pg_listener _isn't_ accessed by the
triggers that are put on the tables, so the REALLY VITAL concern,
namely that we don't want to stop the user's application, is met.
This VACUUM FULL doesn't prevent the user's application from modifying
the application tables and seeing those updates get queued in
sl_log_[12].

I daresay that in my tenure in DB Operations, I have *never* scheduled
a VACUUM FULL of any table (outside of maybe a situation of doing so
by hand during an outage).  Certainly I've never scheduled VACUUM FULL
in a cron...

But on the other hand, I do not see a reason to be overly paranoid
about doing so to the table pg_catalog.pg_listener.
-- 
(format nil "~S@~S" "cbbrowne" "ca.afilias.info")
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)