Re: pg_autovacuum
От | Sim Zacks |
---|---|
Тема | Re: pg_autovacuum |
Дата | |
Msg-id | dnmb3p$nsb$1@news.hub.org обсуждение исходный текст |
Ответ на | Re: pg_autovacuum ("Jim C. Nasby" <jnasby@pervasive.com>) |
Ответы |
Re: pg_autovacuum
|
Список | pgsql-general |
Where can I change the statistic targets? These details for each table are written at the beginning, when I start it. [2005-12-13 12:38:45 IST] INFO: table name: sales."public"."productdetails" [2005-12-13 12:38:45 IST] INFO: relid: 9451256; relisshared: 0 [2005-12-13 12:38:45 IST] INFO: reltuples: 0.000000; relpages: 0 [2005-12-13 12:38:45 IST] INFO: curr_analyze_count: 0; curr_vacuum_count: 0 [2005-12-13 12:38:45 IST] INFO: last_analyze_count: 0; last_vacuum_count: 0 [2005-12-13 12:38:45 IST] INFO: analyze_threshold: 500; vacuum_threshold: 1000 [2005-12-13 12:38:45 IST] DEBUG: added table: sales."public"."productdetails" Jim C. Nasby wrote: > On Tue, Dec 13, 2005 at 10:43:14AM +0200, Sim Zacks wrote: >> This is a sampling of the debug output. >> >> [2005-12-13 09:43:47 IST] DEBUG: 33 All DBs checked in: 278300 usec, >> will sleep for 300 secs. >> [2005-12-13 09:48:47 IST] DEBUG: 34 All DBs checked in: 171112 usec, >> will sleep for 300 secs. >> [2005-12-13 09:53:47 IST] DEBUG: updating the database list >> >> Does that mean that it is vacuuming the databases? >> One major reason that I think it is not, is that after a while the >> system starts getting sluggish and when I run vacuum analyze then it >> picks up again. >> >> That leads me to believe that it is not running vacuum analyze. > > That means that it's most likely just not hitting the statistic targets, > which by default are set so that the table can bloat quite a bit. Try > adding -V 0.2 to your pg_autovacuum command line. > > I think if you up the verbosity one more level it'll give you > information about the stats on the tables it's looking at.
В списке pgsql-general по дате отправления: