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

  1. Do index FSM vacuuming sooner.

  2. Remove UpdateFreeSpaceMap(), use FreeSpaceMapVacuumRange() instead.

  3. While vacuuming a large table, update upper-level FSM data every so often.

  4. Simplify autovacuum work-item implementation