Re: Missing FSM Update when Updating VM On-access

On Fri, Jul 10, 2026 at 10:49 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> On 2026-06-29 18:32:47 -0400, Melanie Plageman wrote:
> > I tried to think of some heuristics so that we could limit when we did
> > the FSM pinning and locking, but none seemed very good. We could check
> > if the new amount of free space is bigger than an FSM category step
> > (32), but that doesn't help us if we are correcting an FSM
> > overestimation. This could happen because inserts don't update the FSM
> > until the inserting tuple doesn't fit on the target page.
>
> One potential heuristic would be to skip trying to update the FSM if the page
> is considered full and we didn't remove any tuples (i.e. just marked it as
> all-visible). Skipping the FSM update in that case would, at worst, lead to
> unnecessarily visiting the page during a future insert (finding it to be full
> when doing so). We could additionally make it depend on whether PD_PAGE_FULL
> is set (in which case we presumably already updated the FSM).
>
> The case where that would potentially help is when doing the first scan
> through a freshly bulk loaded table.
>
> However, compared to the other costs in that case, I have a hard time
> believing the FSM access is that bad. And given the point in the release
> cycle, I think going for simpler is the way to go.

Yea, that's a good heuristic. I pushed the fix without the heuristic
to keep it simple. But then I started thinking about it more, and I'm
second-guessing that decision. I'll create a repro for the case you
mentioned and see if there is a performance difference before
deciding.

> > /*
> > - * We avoid reuse of any free space created on the page by unrelated
> > - * UPDATEs/INSERTs by opting to not update the FSM at this point. The
> > - * free space should be reused by UPDATEs to *this* page.
>
> Does the logic in this removed comment actually make sense to anyone? Because
> it sure doesn't to me. I don't even know what the hell "unrelated"
> UPDATEs/INSERTs means here. We don't have the slightest idea what's related
> and unrelated, assuming that means it's for different tuples than what this
> backend is reading the page for.
>
> Sure, in-page updates are good (hot, general efficiency). But we do update the
> FSM in other places without this consideration, so using that argument to skip
> an FSM update here seems ... bogus.
>
> I could see an argument for not inserting almost full pages into the FSM, but
> if we went for that, it'd not be just this place we'd want to do so.

That comment was added in 42f9427aa98. I think what it means is if
this HOT pruning is happening during the scan that is part of an
UPDATE that we don't want to report the freespace and risk someone
taking it before we can use it during the HOT update we're about to
do. I don't know if there are other places updating the FSM in the
same situation? I tried to include my interpretation of the spirit of
the comment in my revised comment by saying "We do not update the FSM
[when not setting the VM] to reserve freespace on this page for HOT
updates"

- Melanie