On Wed, Sep 27, 2023 at 6:07 PM Andres Freund <and...@anarazel.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
