On Tue, Aug 17, 2021 at 12:11 PM John Naylor
<john.naylor@enterprisedb.com> wrote:
> I'm not sure it's essential to have "far" fewer categories, if the closed-to-open transition is made less granular
throughsome other mechanism.
See my remarks to Andres about FSM_CATEGORIES from earlier. (It may
not matter if you don't believe that it helps us to have such high
granularity -- that means it won't hurt to get rid of it, which might
be a good enough reason on its own.)
> > I now wonder if the FSM is fundamentally doing the wrong thing by
> > keeping track of all "free space" in every page over time. Why
> > wouldn't we just have a free space management strategy that is
> > generally only concerned with recent events?
> The second paragraph here is an interesting idea and makes a great deal of sense. It would lead to smaller FSMs that
arenavigated more quickly and locked for shorter durations.
Most importantly, the FSM/whatever doesn't have to be locked at all if
you don't go to it. And so going to the FSM much less often with space
leases or whatever seems like it might be a big win for that reason
(not just the locality stuff that I care about).
> Implicit "closure" seems riskier in my view if you want to bring VM qualities into it, however.
I didn't mean to imply that we'd be changing that data structure. As I
clarified earlier, "merging the FSM and the VM" was meant in a
conceptual way. Not the best choice of words on my part.
> This makes sense as well. Shared memory for more recent / highly contended state, and disk for less recent / less
contended/ stickier state.
I would like to also make it WAL-logged, which is easier this way.
That isn't my main goal, but why not do it? The way that the FSM works
right now within VACUUM REDO routines is a problem.
--
Peter Geoghegan
