Tom Lane wrote: <snip>
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. :)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.
<snip>
Sounds like this would be beneficial for environments with high update/delete transaction volumes, perhaps on smaller amounts of live/valid data.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.
<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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
