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
signature.asc
Description: OpenPGP digital signature
