On a few occasions I've come across vacuums that result in more pages
stored than needed, ie:
INFO: free space map: 81 relations, 235349 pages stored; 220672 total pages needed
DETAIL: Allocated FSM size: 1000 relations + 2000000 pages = 11817 kB shared memory.
I see that PrintFreeSpaceMapStatistics holds an exclusive lock both while
it counts actual space usage and while it grabs the info used to
calculate pages needed, so it's not a problem of part of that data
changing while the count happens.
I don't think that the issue is PrintFreeSpaceMapStatistics not
accounting for the fact that each relation is guaranteed CHUNKPAGES,
either (I believe sumRequests + numRels handles that).
Any ideas as to what else could cause this problem? If it can't be
figured out, should PrintFreeSpaceMapStatistics at least ensure that
needed >= storedPages? As it stands right now, users need to do that
math in their head when sizing max_fsm_pages, which is a bit confusing.
Another question... while looking through the code, I see that any
GetPageWithFreeSpace ensures that an entry for the relation it was
called for exists by calling create_fsm_rel. create_fsm_rel will create
the entry if needed and put it at the head of the FSM. Doesn't this mean
that a lot of repeated requests to create new tables could 'blow out' a
substantial chunk of the FSM? Or more likely, some periodic process that
updates a large number of tables that don't normally get other requests
for free space would have the same effect. I realize that improving this
would probably involve a non-trivial amount of work, so maybe a good
compromise would be logging a warning anytime a relation is dropped due
to hitting max_fsm_relations.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
