Julian Scarfe <julian.scarfe@ntlworld.com> writes:
> OK, so what's the up-side? :-)
> Will this improve performance, or change disk space requirements, or
> something else?
It'll keep the system from leaking free space in tables, which is what's
causing your tables to bloat. You need an FSM slot for each page that
has useful free space on it, else the system will forget about that
free space.
> What's the rule of thumb, what are the criteria for setting
> these parameters?
Right at the moment I don't think there is any direct way to discover
how big max_fsm_pages needs to be. An upper bound is
select sum(relpages) from pg_class where relkind in ('r','t');
(actually you have to sum over all databases in your installation).
But in most scenarios this is probably overkill, as large tables tend
not to have turnover in every page.
I suppose we should think about adding some more numbers to the VACUUM
output so that one can determine what's happening with the FSM.
regards, tom lane
