Re: Possible explanations for catastrophic performace deterioration?

You didn't specify the database size, but my guess is that the total
data size about enough to fit in shared_buffers or kernel cache.  On
the new system (or dropped/recreated database), it would've all or
mostly fit in memory which would make things like count(*) work
quickly.  On the old database, you probably had a lot of fragmentation
which would've caused significantly more I/O to be performed thereby
causing a slowdown.  You could compare relation sizes to check easily.

My guess is that a vacuum full would've brought the other database
back up to speed.  In the future, you probably want to set fillfactor
to a reasonable amount to account for updates-to-blocks-between-vacuum
to try and capture as few row-migrations as possible.
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation                | fax: 732.331.1301
499 Thornall Street, 2nd Floor          | jonah.harris@enterprisedb.com
Edison, NJ 08837                        | http://www.enterprisedb.com/