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
|
Список | 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 по дате отправления: