On 2025-Mar-19, Christophe Pettus wrote: > Everything seems to point to the vacuum free space map operation, > since it would have a lot of work to do in that particular situation, > it happens at just the right place in the vacuum cycle, and its > resource consumption is not throttled the way the regular vacuum > operation is. > > Assuming this analysis is correct, our current proposal as a temporary > fix is to increase the frequency of autovacuum on those tables, so > that the free space map vacuum operation has less to do, and is less > likely to consume the system. In the longer run, is it worth > considering implementing a cost delay inside of the free space map > update operations?
Assuming this analysis is correct, I agree that the FSM vacuuming should also be throttled, as long as that can be done without blocking concurrent operations (insertions) on the table. Another idea to consider might be to split out the vacuuming of the FSM from the vacuuming of the table itself; given that HOT pruning can free significant amounts of space prior to actual vacuuming, it's possible that there are wins to scheduling it separately. However, having a way to track stats for it might be tricky. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "If you want to have good ideas, you must have many ideas. Most of them will be wrong, and what you have to learn is which ones to throw away." (Linus Pauling)
