From: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Chris <lists(at)deksai(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: stats collector suddenly causing lots of IO |
Date: | 2010-04-16 15:30:27 |
Message-ID: | g2t4ec1cf761004160830q5dff4315rcc0294d342999c35@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, Apr 16, 2010 at 11:23 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Josh Kupershmidt <schmiddy(at)gmail(dot)com> writes:
>> I'm not sure whether this is related to the stats collector problems
>> on this machine, but I noticed alarming table bloat in the catalog
>> tables pg_attribute, pg_attrdef, pg_depend, and pg_type.
>
> Hmm. That makes me wonder if autovacuum is functioning properly at all.
> What does pg_stat_all_tables show for the last vacuum and analyze times
> of those tables? Try something like
>
> select relname,n_live_tup,n_dead_tup,last_vacuum,last_autovacuum,last_analyze,last_autoanalyze from pg_stat_all_tables where schemaname = 'pg_catalog' order by 1;
>
Output attached. Note that I ran pg_stat_reset() a few days ago.
Josh
Attachment | Content-Type | Size |
---|---|---|
pg_stat_all_tables.txt | text/plain | 4.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Yeb Havinga | 2010-04-16 15:33:56 | Re: Planner not using column limit specified for one column for another column equal to first |
Previous Message | Tom Lane | 2010-04-16 15:29:47 | Re: stats collector suddenly causing lots of IO |