Re: Eager page freeze criteria clarification

On Wed, Sep 27, 2023 at 6:07 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I would be sure to look out for new inserts that "unfreeze" pages, too
> > -- ideally you'd have instrumentation that caught that, in order to
> > get a general sense of the extent of the problem in each of your
> > chosen representative workloads. This is particularly likely to be a
> > concern when there is enough space on a heap page to fit one more heap
> > tuple, that's smaller than most other tuples. The FSM will "helpfully"
> > make sure of it. This problem isn't rare at all, unfortunately.
>
> I'm not as convinced as you are that this is a problem / that the solution
> won't cause more problems than it solves. Users are concerned when free space
> can't be used - you don't have to look further than the discussion in the last
> weeks about adding the ability to disable HOT to fight bloat.

All that I said was that it would be a good idea to keep an eye out
for it during performance validation work

> I do agree that the FSM code tries way too hard to fit things onto early pages
> - it e.g. can slow down concurrent copy workloads by 3-4x due to contention in
> the FSM - and that it has more size classes than necessary, but I don't think
> just closing frozen pages against further insertions of small tuples will
> cause its own set of issues.

Of course it'll cause other issues. Of course it's very subtle.

> I think at the very least there'd need to be something causing pages to reopen
> once the aggregate unused space in the table reaches some threshold.

Of course that's true. ISTM that you might well need some kind of
hysteresis to avoid pages ping-ponging. If it isn't sticky, it might
never settle, or take way too long to settle.

--
Peter Geoghegan