1.) is done today, as I was trying to say in the note. We currently
maintain a bit map that either marks pages as completely empty,
or "somewhat" empty. Both sets of pages are used when doing
inserts. There may be more work to get the "somewhat" empty
pages to be used more.
2.) As you say, space is never returned to the OS unless the compress
system procedures are called manually.
Øystein Grøvlen wrote:
"MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
MM> Note that derby does automatically reclaim space from deletes
MM> for subsequent inserts, but the granularity currently is at
MM> a page level. So deleting every 3rd or 5th row is the worst
MM> case behavior. The page level decision was a tradeoff as
MM> reclaiming the space is time consuming so did not want to
MM> schedule to work on a row by row basis. Currently we schedule
MM> the work when all the rows on a page are marked deleted.
It seems like you are mixing two things here:
1. Reclaiming space for subsequent inserts in the same table, and
2. Reclaiming space to the file system (which can be used for
inserts into other tables).
I do not understand why reclaiming of space for 1. should be time
consuming. You can have a list of pages that have lot of free space,
each time you delete a record so that the amount of free space is
above a certain threshold, the page is added to this list.
For 2., it does not seem to happen automatically even for empty pages?
I have today deleted all records of a table with a 440MB file. The
size of the file has not changed.
