On Fri, Aug 20, 2021 at 12:17 PM Peter Geoghegan <pg@bowt.ie> wrote:
> On Fri, Aug 20, 2021 at 9:03 AM Robert Haas <robertmhaas@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
