Re: strange fsm issues

On Jun 22, 2006, at 9:52 AM, Jeff Frost wrote:
> So, I set it to 3366499. I came up with this number by:
> select sum(relpages) from pg_class where relkind in ('r','t');
> and adding that up for all the DBs (there is just the one plus
> postgres and template1 and now I get th efollowing, so it appears
> this was actually a good settings.
>
> CPU 0.00s/0.00u sec elapsed 0.00 sec.
> INFO: free space map contains 3339998 pages in 125 relations
> DETAIL: A total of 3341600 page slots are in use (including
> overhead).
> 3341600 page slots are required to track all free space.
> Current limits are: 3366499 page slots, 2000 relations, using
> 19853 KB.
>
> So then the question is..why was vacuum suggesting such low
> settings previously?

Take a look at the source, but I think the issue is that it stops
trying to keep track after some point.

In any case, for this database I doubt it matters, since there's free
space on every page... afaik any update will first try and add the
new tuple on the current page, so as long as you have enough in the
FSM to handle new inserts it won't matter.

Of course, the fact that you have that much free space on every page
makes me think it's not getting vacuumed enough...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461