Re: Large pgstat.stat file causes I/O storm

From: Cristian Gafton <gafton(at)rpath(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Large pgstat.stat file causes I/O storm
Date: 2008-01-29 19:45:38
Message-ID: Pine.LNX.4.64.0801291433250.19796@alienpad.rpath.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 29 Jan 2008, Tom Lane wrote:

> Cristian Gafton <gafton(at)rpath(dot)com> writes:
>> Autovacuum is disabled, since the database is mostly read only. There is a
>> "vacuumdb -a -z" running nightly on the box. However, the application that
>> queries it does a lot of work with temporary tables - would those bloat
>> the stats at all?
>
> Conceivably, if you mean a lot of short-lived tables rather than a lot
> of operations on a few tables. However, I'd think that would result in
> a steady accumulation of stats entries, not a sudden jump as you seemed
> to describe.

We are churning through a bunch of short-lived temp tables. Since I
reported the problem, the pgstat file is now sitting at 85M, yet the
pg_stat* tables barely have any entries in them:

count(*)
pg_stats 298
pg_statistic 298
pg_stat_all_indexes 76
pg_stat_all_tables 76
pg_statio_all_tables 56
pg_statio_all_indexes 76

Is there a way to inspect the pgstat file and see what's in it that it is
taking all this space? (it's not the space that bothers me, it's the fact
that the statistics collector has to dump 85MB of stuff once a second to
disk...)

Thanks,

Cristian
--
Cristian Gafton
rPath, Inc.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-01-29 20:12:41 Re: Large pgstat.stat file causes I/O storm
Previous Message Tom Lane 2008-01-29 19:20:45 Re: Large pgstat.stat file causes I/O storm