On Tue, Aug 17, 2021 at 12:11 PM John Naylor <john.nay...@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 through some 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 are navigated 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
