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-24T19:17:54Z
Lists: pgsql-hackers
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. This approach would also offer a less arbitrary way to decide how often to do the updates: choose a distance that has something to do with the FSM's structure, so that we don't waste effort reconsidering fragments of an upper tree page. 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