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
