Re: Calculation for Max_FSM_pages : Any rules of thumb?
От | Tom Lane |
---|---|
Тема | Re: Calculation for Max_FSM_pages : Any rules of thumb? |
Дата | |
Msg-id | 18752.1193966525@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Calculation for Max_FSM_pages : Any rules of thumb? (Ow Mun Heng <Ow.Mun.Heng@wdc.com>) |
Ответы |
Re: Calculation for Max_FSM_pages : Any rules of thumb?
|
Список | pgsql-general |
Ow Mun Heng <Ow.Mun.Heng@wdc.com> writes: > OK.. Vacuum verbose took 2 hours.. Vacuum full will likely take 2x that > I presume. Probably a lot more, and it'll bloat your indexes while it's at it. Do you have a *reason* to run a vacuum full? I'd suggest using contrib/pgstattuple to get a fix on how much dead space there is in your tables. If it's really horrid (like more than 50%) then VACUUM FULL followed by REINDEX might be called for, but otherwise you should probably not sweat it. If you do have a problem you need to reconsider your regular vacuuming policy, because it's not running often enough. See if autovacuum makes sense for you. Also, if you are not low on disk space overall, consider CLUSTER as a substitute for VACUUM FULL + REINDEX. It'll be faster and you might get a speed boost for subsequent queries using whichever index you cluster on. The only drawback is that CLUSTER uses temp space equal to the table + index sizes ... regards, tom lane
В списке pgsql-general по дате отправления: