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

Поиск
Список
Период
Сортировка
От Cristian Gafton
Тема Re: Large pgstat.stat file causes I/O storm
Дата
Msg-id Pine.LNX.4.64.0801291433250.19796@alienpad.rpath.com
обсуждение исходный текст
Ответ на Re: Large pgstat.stat file causes I/O storm  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Large pgstat.stat file causes I/O storm  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Large pgstat.stat file causes I/O storm
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Large pgstat.stat file causes I/O storm