"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