db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Created: (DERBY-510) DERBY-132 resolved ? Table not automatically compressed
Date Wed, 17 Aug 2005 19:30:37 GMT
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 <mikem_app@sbcglobal.net> 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.
> 


Mime
View raw message