Re: Brain dump: btree collapsing

Tom Lane wrote:
<snip>
> The deletion procedure could be triggered immediately upon removal of the
> last item in a page, or when the next VACUUM scan finds an empty page.
> Not sure yet which way is better.

Having it triggered immediately upon removal of the last item in a page 
would make for a more "self maintaining" system wouldn't it?  That 
sounds nice.  :)

<snip>
> In theory, if we find recyclable page(s) at the physical end of the index,
> we could truncate the file (ie, give the space back to the filesystem)
> instead of reporting these pages to FSM.  I am not sure if this is worth
> doing --- in most cases it's likely that little space can be released this
> way, and there may be some tricky locking issues.

Sounds like this would be beneficial for environments with high 
update/delete transaction volumes, perhaps on smaller amounts of 
live/valid data.


<snip>
> This could be ignored in first implementation (there's always REINDEX).
> Later, possibly handle it via Lanin&Shasha's notion of a critic (think
> VACUUM) that sets a fast pointer to the current effective root level.
> (Actually I think we wouldn't need a separate critic process; split and
> delete steps could be programmed to update the fast pointer for
> themselves, in a separate atomic action, when they split a one-page level
> or delete the next-to-last page of a level.)

This really sounds like good initial thoughts too.

:-)

Regards and best wishes,

Justin Clift

-- 
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."   - Indira Gandhi