Re: Relation forks & FSM rewrite patches - Mailing list pgsql-patches

From Alvaro Herrera
Subject Re: Relation forks & FSM rewrite patches
Date
Msg-id 20080704163643.GB3893@alvh.no-ip.org
Whole thread Raw
In response to Re: Relation forks & FSM rewrite patches  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Responses Re: Relation forks & FSM rewrite patches  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List pgsql-patches
Heikki Linnakangas wrote:
> Simon Riggs wrote:

>> What if we bubbled up based
>> upon only significant tree changes, rather than exact changes?
>
> Hmm. So an update would only ever update the lowest-level FSM page, and
> leave a mismatch between the value at the root node of a lower level FSM
> page, and the corresponding value at the lead node of its parent. The
> mismatch would then need to be fixed by the next search that traverses
> down that path, and finds that there's not enough space there after all.
>
> That works when the amount of free space on page is decremented. VACUUM,
> that increments it, would still need to bubble up the change, because if
> the value at the upper level is not fixed, no search might ever traverse
> down that path, and the value would never be fixed.

I wonder if we could instead make vacuum write a new FSM tree from
scratch, rather than updating it piecemeal.  The problem that arises is
a concurrent updater.  Maybe we can just ignore those (i.e. someone that
consumes free space while vacuum is running does not update the FSM),
and let the bogus values (which can be higher, but not lower, than the
actual free space) be updated later, when someone tries to use it and
finds that it's not correct.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

pgsql-patches by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Sorting writes during checkpoint
Next
From: "Dave Page"
Date:
Subject: Re: Explain XML patch v2