Claudio Freire <klaussfre...@gmail.com> writes: > On Sat, Mar 24, 2018 at 4:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> I hadn't paid any attention to this patch previously, so maybe I'm >> missing something ... but this sure seems like a very bizarre approach >> to the problem. If the idea is to fix the FSM's upper levels after >> vacuuming a known sub-range of the table, why would you not proceed >> by teaching FreeSpaceMapVacuum to recurse only within that sub-range >> of page numbers? This setup with a threshold seems entirely Rube >> Goldbergian. It's dependent on a magic threshold number that you can >> only select by trial and error, and it's inevitably going to spend time >> updating segments of the FSM tree that have nothing to do with the part >> that's been vacuumed.
> Well, the point is to not only update the range we know we've > vacuumed, but also to finish the updates done by a potential > previously cancelled autovacuum. I think that's not an important consideration, or at least would stop being one after a patch like this. The reason it's a problem now is precisely that we don't try to vacuum the FSM till the very end; if we did FSM cleanup every X pages --- in particular, before not after the final relation-truncation attempt --- there wouldn't be risk of skipping so much FSM work that we need to worry about forcing the issue just in case there'd been a prior cancellation. (Of course, you'd still need to do something after the truncation step to truncate the FSM, but I'm arguing it should *only* respond to that, not have to clean up all the rest of the FSM state.) regards, tom lane