Re: Cause of moving-target FSM space-needed reports

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.

Thanks,
Markus

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

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