| 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: | Whole Thread | Raw Message | 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 |