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@xxxxxxxxxxxxx
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
