Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently
Claudio Freire <klaussfreire@gmail.com>
From: Claudio Freire <klaussfreire@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2018-03-26T17:46:07Z
Lists: pgsql-hackers
Attachments
- 0001-Vacuum-Update-FSM-more-frequently-v10.patch (text/x-patch) patch v10-0001
- 0002-Vacuum-do-a-partial-FSM-vacuum-at-the-beginning-v5.patch (text/x-patch) patch v5-0002
- 0003-Vacuum-free-dead-tuples-array-as-early-as-possible-v5.patch (text/x-patch) patch v5-0003
- 0004-Index-vacuum-Vacuum-FSM-after-each-bulkdelete-call-v2.patch (text/x-patch) patch v2-0004
On Mon, Mar 26, 2018 at 11:26 AM, Claudio Freire <klaussfreire@gmail.com> wrote: > On Mon, Mar 26, 2018 at 11:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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. > > I'm thinking that in conjunction with the high MWM patch for vacuum, > it could still happen that considerable amount of vacuuming is left > unexposed upon cancellation. > > The "bizarre" approach provides some relief. > > I'll see about implementing the FSM range vacuuming operation for > non-initial runs, there seems to be consensus that it's a good idea. > > But I still think this partial run at the very beginning is useful still. Attached patches, rebased and modified as discussed: 1 no longer does tree pruning, it just vacuums a range of the FSM 2 reintroduces tree pruning for the initial FSM vacuum 3 and 4 remain as they were, but rebased
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