Ok, it doesn't look like an autovacuum problem. The only other thing I
can think of is that some query is doing a seq scan rather than an index
scan. Have you turned on the query logging to see what queries are
taking so long?
Matt
Robert Creager wrote:
I am, and it is. It's ANALYZING and VACUUM'ing tables every interval (5 minutes
- 8.0.3). Right now, for that last 4 hours, I'm not VACUUMing the 7.4.1
database and it's still clicking along at < .2 second queries. Last year
(7.4.1), I noticed that it took about a week of heavy activity (for this DB)
before I'd really need a vacuum. That's when I put in the 5 min cron.
When I first switched over to 8.0.3, I was still running the cron vacuum. I got
into big trouble when I had vacuum's backed up for 6 hours. That's when I
started noticing the query problem, and the CS numbers being high. 7.4.1
vacuums every 5 minutes always take < 30 seconds (when I'm watching).
Cheers,
Rob
When grilled further on (Sun, 17 Jul 2005 23:48:20 -0400),
"Matthew T. O'Connor" <matthew@zeut.net> confessed:
Robert Creager wrote:
For 8.03, pg_autovacuum is running. On 7.4.1, I set up a cron job to vacuum
analyze every 5 minutes.
Are you sure that pg_autovacuum is doing it's job? Meaning are you sure
it's vacuuming as often as needed? Try to run it with -d2 or so and
make sure that it is actually doing the vacuuming needed.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
