Tom Lane wrote:
I think it's reasonable for vacuumlazy.c to track at most MaxFSMPages
pages as it's doing now --- but it should keep a separate count of the
total number of pages with at least threshold amount of free space, and
pass that as a separate argument to RecordRelationFreeSpace. This will
not take any more space in shared memory than we already use, but it
will allow us to report a truthful value for "number of pages needed",
which we clearly are failing to do now.
It might also be a good idea if vacuum verbose reported this page count,
since when you've got a single table bloated like this, VACUUM FULL or
CLUSTER might be a more appropriate solution than increasing the FSM
size --- but there's no way to know which rel is the problem from the
FSM total. In fact, maybe vacuum should just throw a WARNING when it
finds a single rel with more than MaxFSMPages pages with useful free space?
Comments? I'd like to put in a fix for beta1, which means today ...
Sounds reasonable - it's arguably a bug, albeit relatively benign. I
guess it might be less likely in 8.2 anyway given that we will have more
generous default max_fsm_pages settings in most cases.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
