Re: Postgres performance slowly gets worse over a month
От | Gaetano Mendola |
---|---|
Тема | Re: Postgres performance slowly gets worse over a month |
Дата | |
Msg-id | 015601c23303$58a63040$d60ffea9@GMENDOLA2 обсуждение исходный текст |
Ответ на | Re: Postgres performance slowly gets worse over a month (Naomi Walker <nwalker@eldocomp.com>) |
Ответы |
Re: Postgres performance slowly gets worse over a month
|
Список | pgsql-admin |
"Michael G. Martin" <michael@vpmonline.com> wrote: > Check this value in the postgresql.con file: > > max_fsm_pages = 100000 > > I had the same problem with the db growing, index no longer being used, > despite vacuums each night. Somewhere, there is a thread on this. > > Anyway, If you look at the vacuum stats each time your run vacuum, looks > to see how many pages are being updated between vacuums--i looked at the > removed x tuples in y pages value. Then, set this value to be greater > than the number of pages changed between vacuums. If more pages are > being updated between vacuums than what max_fsm_pages allows, the extra > pages won't be marked to be re-used--from what I understand. This then > results in the db growing and the optimizer starts to chose full table > scans since the db spans so many pages on the disk--at least this is > what happened in my db. Can you explain me this line that I obatin in the log after a vacuum analyze ? --Relation ua_user_data_exp-- 2002-07-21 05:00:02 [28492] DEBUG: Pages 1402: Changed 2, reaped 1192, Empty 0, New 0; Tup 4277: Vac 16207, Keep/VTL 0/0, Crash 0, UnUsed 1, MinLen 393, MaxLen 680; Re-using: Free/Avail. Space 9148944/9141356; EndEmpty/Avail. Pages 0/1191. CPU 0.00s/0.03u sec. I'm wondering about "Re-using: Free/Avail. Space 9148944/9141356" Ciao Gaetano
В списке pgsql-admin по дате отправления: