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 |/
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
