On Fri, Aug 20, 2021 at 12:17 PM Peter Geoghegan <p...@bowt.ie> wrote: > On Fri, Aug 20, 2021 at 9:03 AM Robert Haas <robertmh...@gmail.com> wrote: > > That could be the right decision, but nothing said up to this point > > really seems to suggest it. The open/closed distinction and the > > changes in how to bin available space could all be done with the > > present model. > > I guess that's true. Isn't this just semantics, though?
Not entirely. On one level, as long as we end up with an FSM implementation that does good things, who cares how it works internally? Well, the answer is, hackers care, and we're hackers, so it doesn't seem out of bounds to talk about thoughts and ideas around that. My own opinion is that the multi-level implementation of the current FSM is confusing and doesn't seem to do what we want, but the basic idea of a direct-mapped data structure seems good to me. Life is a lot simpler if you can update the status of your own page without having to do any complex calculation to figure out where that status is stored, let alone having to shuffle things around to make room to insert your status. Now if you or someone else comes up with an absolutely amazing new design that isn't direct-mapped and it's awesome, I'm not going to sit here and hold my breath; I like awesome as well as the next person. But if you or someone else said to me "hey, Robert, I'm thinking of rewriting the FSM, what tips do you have for maximizing the chances of success?" I'd say "well, you should try to make the replacement data structure as simple as it can be while still having the other properties that you care about ... and in particular I would suggest something that uses a fixed amount of state per heap page, because that seems much simpler to me." But nobody's got to agree with that, and it doesn't have to be right. It's just what I think. -- Robert Haas EDB: http://www.enterprisedb.com