Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently
Date: 2018-03-26 17:46:07
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Mon, Mar 26, 2018 at 11:26 AM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Mon, Mar 26, 2018 at 11:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Claudio Freire <klaussfreire(at)gmail(dot)com> writes:
>>> On Sat, Mar 24, 2018 at 4:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

Attachment Content-Type Size
0001-Vacuum-Update-FSM-more-frequently-v10.patch text/x-patch 11.1 KB
0002-Vacuum-do-a-partial-FSM-vacuum-at-the-beginning-v5.patch text/x-patch 8.7 KB
0003-Vacuum-free-dead-tuples-array-as-early-as-possible-v5.patch text/x-patch 2.7 KB
0004-Index-vacuum-Vacuum-FSM-after-each-bulkdelete-call-v2.patch text/x-patch 3.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2018-03-26 17:47:23 Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently
Previous Message Ildus Kurbangaliev 2018-03-26 17:38:25 Re: [HACKERS] Custom compression methods