On Fri, Aug 20, 2021 at 10:15 AM Robert Haas <robertmh...@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
