Hi, Tom,

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?

+1 for both from my side, it has bitten me and our admins several times now.


Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in Europe! www.ffii.org

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to