Re: [HACKERS] Re: pgsql: Fix free space map to correctly track the total amount of FSM
От | Decibel! |
---|---|
Тема | Re: [HACKERS] Re: pgsql: Fix free space map to correctly track the total amount of FSM |
Дата | |
Msg-id | D9BA2275-28B4-403A-A349-597A7AB14A7B@decibel.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: pgsql: Fix free space map to correctly track the total amount of FSM (Tatsuo Ishii <ishii@postgresql.org>) |
Список | pgsql-committers |
Dropping -committers. On Oct 2, 2007, at 10:37 AM, Tatsuo Ishii wrote: >> Tatsuo Ishii <ishii@postgresql.org> writes: >>> Sorry for replying to very old message. But... it seems this was not >>> backported to 8.1 or earlier. >> >> Since it involved a change in the FSM API, it didn't seem reasonable >> to back-patch it. > > So for those versions of PostgreSQL the only way to know the > appropriate FSM pages is change FSM-restart postmaster-do vacuum cycle > until vacuum reports the same number of "total page needed"? That's the only easy way I know of, but there is something that might make life easier if you're using autovacuum... take SELECT sum (relpages) FROM pg_class and multiply that by autovacuum_vacuum_scale_factor. If autovac is doing a reasonable job of keeping up, that should be a maximum of what you'd need in the FSM. Hrm... what about adding output to vacuum verbose that indicates how many pages in a relation have free space? That would allow something like pgfouine to see how many FSM pages were needed. It would also make it easier to identify relations that could stand a vacuum full/ reindex/cluster (though you'd also want to know something like average free space per page). -- Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
В списке pgsql-committers по дате отправления: