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(dot)harris(at)enterprisedb(dot)com
Edison, NJ 08837 | http://www.enterprisedb.com/