From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | FSM pages stored v. pages needed |
Date: | 2005-11-08 01:55:21 |
Message-ID: | 20051108015521.GN19551@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | mike | 2005-11-08 03:56:17 | Copy From CSV feature request? |
Previous Message | Tom Lane | 2005-11-08 00:09:04 | Supporting NULL elements in arrays |