At 01:46 PM 3/05/2004, Tom Lane wrote:
>If it takes half an hour to ANALYZE pg_listener, I think that ANALYZE is
>not your real problem :-(. You need a much more aggressive vacuuming
>policy on that table. Maybe a cron job issuing "vacuum pg_listener"
>once a minute would do? And get the size of the table knocked down to
>something less stratospheric to begin with --- perhaps stop all the
>listeners while you TRUNCATE the table.
It's a general ANALYZE command for the entire DB. It's about 6GB in size,
and is vacuumed as frequently as possible; there is certainly unreclaimed
space, but it does not substantially outweigh used space. My *guess* is
that the largest table is being ANALYZEd at the time (it uses most of the
6GB), and for some reason pg_listeners is being locked in ACCESS SHARE the
entire time.
Just vacuuming pg_listener produces:
vacuum verbose pg_listener;
INFO: vacuuming "pg_catalog.pg_listener"
INFO: "pg_listener": found 0 removable, 0 nonremovable row versions in 0 pages
VACUUM
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp.mit.edu:11371 |/