Re: The Free Space Map: Problems and Opportunities - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: The Free Space Map: Problems and Opportunities
Date
Msg-id CAH2-WzmrckN+OC8jHkPjRFkQiuhKXuj8Wd0GEteMja-3XnyysA@mail.gmail.com
Whole thread Raw
In response to Re: The Free Space Map: Problems and Opportunities  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: The Free Space Map: Problems and Opportunities  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Aug 20, 2021 at 12:20 PM Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Aug 20, 2021 at 3:13 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > In short: yeah, this "closed vs open" page business more or less
> > necessitates tightening things up here. Though this new requirement
> > seems to have always been a good idea. Just because we can lean on
> > VACUUM like this (an option that other DB systems don't have) doesn't
> > mean that we should do so.
>
> That's all true, but it's not what I was talking about.

Then I am not sure that I have understood you fully. I would like to
make sure that I have the nuance of it. As long as we have the idea of
open vs closed pages then we cannot assume that we know that status
from the page alone. Unless we're willing to go update the pages
again, and possibly dirty them again, which seems unappealing.

My concern here is really the data structure and its overall
complexity. If there has to be an explicit state for every page on the
FSM, then this new FSM needs to merge freelists that have been emptied
into that structure, and needs to handle the question of which
structure (map or free lists) is currently authoritative for a given
heap page. That's a lot of complexity compared to just forgetting the
free lists that are known to be fully closed, which will probably be
very common. That can work a little like discarding old UNDO -- it can
be simple and cheap *because* it's largely logical and implicit at the
level of the physical data structures.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Cary Huang
Date:
Subject: Re: postgres_fdw: Handle boolean comparison predicates
Next
From: "Bossart, Nathan"
Date:
Subject: Re: archive status ".ready" files may be created too early