From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org> |
Cc: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: CPU-intensive autovacuuming |
Date: | 2005-06-07 16:42:03 |
Message-ID: | 9559.1118162523@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org> writes:
> (Incidentally, I have also found that the indexes on my pg_attributes
> table were taking up over half a gigabyte, which came down to less than
> 40 megs after reindexing them. Is there a case for having autovacuum
> also call reindex?)
Lots of temp tables I suppose? If so that's not autovacuum's fault;
it wasn't getting told about the activity in pg_attribute until this
patch:
2005-03-31 18:20 tgl
* src/backend/postmaster/: pgstat.c (REL7_4_STABLE), pgstat.c
(REL8_0_STABLE), pgstat.c: Flush any remaining statistics counts
out to the collector at process exit. Without this, operations
triggered during backend exit (such as temp table deletions) won't
be counted ... which given heavy usage of temp tables can lead to
pg_autovacuum falling way behind on the need to vacuum pg_class and
pg_attribute. Per reports from Steve Crawford and others.
Unless the bloat occurred after you updated to 8.0.2, there's no issue.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-06-07 16:49:44 | Re: Update sql question |
Previous Message | Don Isgitt | 2005-06-07 16:34:25 | Re: Update sql question |
From | Date | Subject | |
---|---|---|---|
Next Message | Victor Y. Yegorov | 2005-06-07 16:52:57 | Re: adding new pages bulky way |
Previous Message | Tom Lane | 2005-06-07 16:38:08 | Re: copying a bucket to a BufFile |