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-26T14:07:52Z
Lists: pgsql-hackers
On Sat, Mar 24, 2018 at 4:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Claudio Freire <klaussfreire@gmail.com> writes: >> [ 0001-Vacuum-Update-FSM-more-frequently-v9.patch ] > > 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. But I guess that's only for the first run. Your approach seems like a better idea for the other runs. Just FTR, the number isn't so magic. During vacuum, the patch records the highest amount of free space produced, and will only recurse into branches that don't already record that much free space. So it's quite deterministic in those cases, it's only the first run the one that has to guess, and your approach doesn't apply for that first run.
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