On Fri, Aug 20, 2021 at 10:15 AM Robert Haas <robertmhaas@gmail.com> wrote:
> > 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?
> 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.
But not storing information about a heap page implicitly means that
the page is closed. And so we effectively remember the state of every
single heap page with the FSM design I am working on. Not storing any
information in the data structure is just an optimization. In any case
we're obligated to have accurate information about all individual heap
pages.
Doing it that way seems pretty natural to me, even though the overhead
of maintaining the FSM data structure isn't a priority for me -- not
at all. It might actually be easier to have that optimization than to
not have it. The starting point for the new FSM data structure is
lists of blocks that are usable, that have free space. Whereas the
starting point for the existing FSM structure is every single extant
heap page in the table -- it's strictly obligated to have explicit
information about every single page (otherwise we get nasty smgr
errors). It's either a small difference or a big difference, depending
on how you think about it.
--
Peter Geoghegan
