On Mon, Mar 26, 2018 at 11:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
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.
