Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group