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-04-03T13:17:59Z
Lists: pgsql-hackers
On Thu, Mar 29, 2018 at 7:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> I have to go do something
>> else right now, but I'll take a closer look at 0004 later.
>
> OK, so after studying 0004, it seems to me that we could do it more
> simply as attached; that is, move the IndexFreeSpaceMapVacuum calls
> into btvacuumscan/spgvacuumscan, do them only if we found any recyclable
> pages, and drop the calls in btvacuumcleanup/spgvacuumcleanup altogether.
>
> The reason I think this is sufficient is that the scans find and record
> every reusable page in the index, no matter whether they were recorded
> before or not.  Therefore, if we don't find any such pages, there's
> nothing useful in the FSM and no particular urgency about making its
> upper pages up-to-date.  It's true that if the FSM is actually corrupt,
> leaving that to be fixed retail by searches is probably less efficient
> than doing an IndexFreeSpaceMapVacuum call would be --- but *only* if
> you assume that the problem is just in the upper pages and the leaf
> pages are all fine.  That doesn't seem to be a case we should optimize
> for.

+1, LGTM.


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