Re: The Free Space Map: Problems and Opportunities

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Jan Wieck <jan(at)wi3ck(dot)info>, Gregory Smith <gregsmithpgsql(at)gmail(dot)com>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: The Free Space Map: Problems and Opportunities
Date: 2021-08-20 19:40:08
Message-ID: CAH2-WzmrckN+OC8jHkPjRFkQiuhKXuj8Wd0GEteMja-3XnyysA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 20, 2021 at 12:20 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Aug 20, 2021 at 3:13 PM Peter Geoghegan <pg(at)bowt(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bossart, Nathan 2021-08-20 19:41:28 Re: archive status ".ready" files may be created too early
Previous Message Cary Huang 2021-08-20 19:33:12 Re: postgres_fdw: Handle boolean comparison predicates