From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently |
Date: | 2018-02-15 20:00:50 |
Message-ID: | CAGTBQpZBPF2UOAcGe7eWOP7sOe=POXq-fz_9vd7yeaJB9XRtRw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 15, 2018 at 4:47 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Wed, Feb 14, 2018 at 3:59 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-02-15 21:35:18 | Re: [PATCH][PROPOSAL] Add enum releation option type |
Previous Message | Claudio Freire | 2018-02-15 19:47:48 | Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently |