On Thu, Feb 15, 2018 at 4:47 PM, Claudio Freire <klaussfre...@gmail.com> wrote: > On Wed, Feb 14, 2018 at 3:59 AM, Masahiko Sawada <sawada.m...@gmail.com> > wrote:
>>> The final FSM vacuum pass isn't partial, to finally correct all those >>> small inconsistencies. >> >> Yes, but the purpose of this patch is to prevent table bloating from >> concurrent modifications? > > Yes, by *marking* unmarked space. If the slot is above the threshold, > it means there's already marked free space on that branch, and search > will go into it already, so no pressing need to refine the mark. The > space already marked can serve while vacuum makes further progress. > Ie: it can wait. Although... I think I see what you mean. If you have this: 255 . 0 . . 0 . . 255 . 0 . . 64 . . 64 . 0 . . 0 . . 64 A partial vacuum won't even recurse beyond the root node, so it won't expose the free space 2 levels down. This could be arrived at by having an almost fully packed table that contains some free space near the end, and it gets deletions near the beginning. Vacuum will mark the leaf levels at the beginning of the table, and we'd like for that free space to be discoverable to avoid packing more rows near the end where they prevent truncation. The patch as it is now will only vacuum that part of the FSM when the root value drops, which usually requires all the free space on that region of the heap to be exhausted. With the current recursive FSM vacuum method, however, that's unavoidable. We can't detect that there's some free space below the current level to be exposed without recursing into the tree, and recursing is exactly the kind of work we want to prevent with tree pruning. In all my trials, however, I did not run into that case. It must not be easy to get into that situation, because the root node already has ~4000 slots in it. Each of those 4000 slots should be in that situation to keep the space at the end of the table as the sole discoverable free space, which seems like a rather contorted worst case.
