Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Claudio Freire <klaussfreire@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2018-03-26T14:19:35Z
Lists: pgsql-hackers
Claudio Freire <klaussfreire@gmail.com> writes: > On Sat, Mar 24, 2018 at 4:17 PM, Tom Lane <tgl@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
Commits
-
Do index FSM vacuuming sooner.
- c79f6df75dd3 11.0 landed
-
Remove UpdateFreeSpaceMap(), use FreeSpaceMapVacuumRange() instead.
- a063baaced27 11.0 landed
-
While vacuuming a large table, update upper-level FSM data every so often.
- 851a26e26637 11.0 landed
-
Simplify autovacuum work-item implementation
- 31ae1638ce35 11.0 cited