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.
In response to
pgsql-patches by date
|Next:||From: Dave Page||Date: 2008-07-04 18:38:13|
|Subject: Re: Explain XML patch v2|
|Previous:||From: Simon Riggs||Date: 2008-07-04 16:22:23|
|Subject: Re: Sorting writes during checkpoint|