Re: stats collector suddenly causing lots of IO

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

In response to

Responses

Browse pgsql-performance by date

  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