Claudio Freire <klaussfreire@gmail.com> writes:
> v10 counted the number of blocks with updated free space to vacuum the
> FSM only after a lot of changes to it were made. This will vacuum the
> FSM after *scanning* a lot of pages, even if little modifications were
> made to them.
Yes, that's exactly the point. We still need to update the upper pages of
the FSM, regardless of exactly how many pages were changed by VACUUM
underneath. The pages VACUUM didn't change might still be out of date in
the upper pages, since retail updates from other operations don't
immediately propagate; so there's a fixed amount of work that needs to be
done there and we might as well do it in more-or-less-predictable quanta.
I don't see any point in adding counting overhead/complexity for that.
In fact, I seriously considered just making it update after every
VACUUM_FSM_EVERY_PAGES period, but decided that for the case with indexes,
doing it right after each cleanup cycle was sensible, and then we might as
well make the no-index case look as much like that as we conveniently can.
The no-index case seems vestigial anyway; how often is that really going
to apply? So spending a lot of complexity on it doesn't seem warranted,
especially when the argument for more complexity is at best dubious.
> This doesn't seem correct.
[ thinks for a bit... ] Yeah, you're right, we need to round up not down
when determining the last slot to scan on the upper level.
I wonder how hard it is to avoid rounding up when the stop point actually
does fall right at a FSM page boundary. OTOH, that might not happen often
enough to be worth sweating over.
regards, tom lane
