달리 답이 없습니다. 
vacuum 관련은 autovacuum과 cron 으로 vacuum 작업을 주기적으로 하는 방법을 
테이블에 따라 구분해서 사용하는 방법이 제가 보기에는 가장 합리적인 것 같고요. 

워낙 광범위한 부분의 질문인지라, 
할 수 있는 말은, 

첫번째는 사용하는 각 쿼리들이 최적화 되어있는지부터 살펴보셔야할 것 같고요. 
로그에서 실행시간이 많이 걸리는 쿼리들만 로그를 남겨 고질적으로 기록되는 쿼리들의 문제점을 
찾는 방법이 비교적 빠른 방법입니다. 

두번째는 환경설정 파일에서 적당한 - 이놈이 아주 모호하죠. ^^ - 값들로 설정되어있는지 살펴보시면 되구요. 이 값들은 대부분 기본 값들을 쓰면 될 것이고, 메모리가 넉넉하다면, vacuum 때와 sort 할 때의 메모리를 많이 늘려주시면 될 것이고, 
실시간 로그 관련은 시간당 트랜잭션의 처리량에 따라 적당량으로 늘려주면 될것이고, 이것은 친절하게 로그에서 알려줍니다. 
그 외에는 대부분 기본값 그대로 써도 무방합니다. 

세번째는 하드웨어적으로 적당한지, 판단을 하셔야할 것같고요. os의 vmstat, top 같은 명령으로 모니터링을 해 보면 하드웨어적으로 적당한지를 결정하셔야할 것같네요.
소프트웨어적으로 해 볼 수 있는 것은 다 했음에도 불구하고 영 답이 안나온다면, 하드웨어를 바꾸는 수 밖에요. ^^

네번째는 그래도 문제가 있다면, 자료구조를 바꾸는 것입니다. 
자료가 저장되는 량을 줄이든지, 분산처리를 하든지... 기타 등등...

제가 지금 일하고 있는 곳의 자료 처리가 많이 쌓이는 날이면 하루에 약 10만건 정도 쌓입니다. 
메모리 4GB이고, 3GHz dual cpu 에서 시스템 사용량이 약 40%정도 됩니다. 이론상으로는 20만건 정도 되어도 하드웨어적으로는 견딜 것이다고 가정은 하고 있습니다. 
즉, 잘 튜닝하면 기대하는 성능은 발휘해 줄것이라고 우기고싶네요. ^^

꽤나 많은 부분을 함께 고려해야할 상황인지라, 딱히 뭐하 꼬집어서 언급해야할 부분이 없는 것 같습니다.

상기님 말씀처럼 워낙 광범위한 문제라서 한마디로 말씀드릴 수 있는게 아닐 것 같네요.

vacuum도 중요하지만 update가 빈번한 table의 경우 analyze를 적절하게 수행해서 옵티마이저가 올바른 쿼리 플랜을 만들 수 있도록 해줘야 하구요.

수시로 쿼리가 효율적으로 돌아가는지 explain을 떠보시는게 좋습니다. 만약 의도한 쿼리 플랜 아니라면 DB 설정을 좀 바꿔줄 필요가 있습니다.

postgresql의 기본 설정값들은 약간 보수적으로 잡혀있어서 성능이 좋은 H/W에서는 좀 공격적으로 바꿔주는 것이 좋더군요.

하지만 좋은 DB 설계보다 효과적인 성능 향상 방법은 없는 것 같습니다. ^^

저는 하루 평균 40만건 정도가 쌓이는 DB를 운영중입니다. CRM 시스템이라서 이 자료들로 실시간 통계를 내야하구요.