Re: Large pgstat.stat file causes I/O storm - Mailing list pgsql-hackers

From Cristian Gafton
Subject Re: Large pgstat.stat file causes I/O storm
Date
Msg-id Pine.LNX.4.64.0801291433250.19796@alienpad.rpath.com
Whole thread Raw
In response to Re: Large pgstat.stat file causes I/O storm  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Large pgstat.stat file causes I/O storm  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 29 Jan 2008, Tom Lane wrote:

> Cristian Gafton <gafton@rpath.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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Large pgstat.stat file causes I/O storm
Next
From: Tom Lane
Date:
Subject: Re: Large pgstat.stat file causes I/O storm