You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mike Matrigali (JIRA)" <de...@db.apache.org> on 2005/01/24 23:33:17 UTC
[jira] Assigned: (DERBY-132) in place table/index compress which returns space to OS
[ http://issues.apache.org/jira/browse/DERBY-132?page=history ]
Mike Matrigali reassigned DERBY-132:
------------------------------------
Assign To: Mike Matrigali
> in place table/index compress which returns space to OS
> -------------------------------------------------------
>
> Key: DERBY-132
> URL: http://issues.apache.org/jira/browse/DERBY-132
> Project: Derby
> Type: Improvement
> Components: Store
> Versions: 10.1.0.0
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
>
> Each derby table or index is stored in a separate file. Space from
> deleted rows is eventually reclaimed within the file as is used for
> subsequent inserts into the same file. That space is not returned to
> the OS unless the user calls the SYSCS_UTIL.SYSCS_COMPRESS_TABLE
> system procedure. That procedure will return the unused space in
> the tables and indexes to the OS. It gets an exclusive lock on the
> table, copies all rows in the indexes and the base table into new
> compressed files and delete the old files. Prior to jdk 1.4 this was
> the only way to return space from a file to the OS.
> In jdk 1.4 RandomAccessFile was enhanced to allow the truncation of a
> file, which would return the space at the "end" of the file back to
> the OS. In order to take advantage of this new feature a new
> compress feature is needed in derby.
> The assumption is that this work will be used in future work which will
> automatically schedule this job and others in background, with no
> interaction needed from the dba. The 1st phase of this work will
> simply build a procedure that will do the work. The 2nd phase will
> be to look into scheduling the procedure automatically as part of
> the current background post commit processing. Longer term it would
> be best if this fit into a new background task monitor, which could
> schedule larger background tasks balanced against the other priorities
> of the system. These tasks might include: this new online compress,
> automatic statistics gathering, more proactive deleted row reclamation, ....
> The proposed feature will reorganize base tables and indexes, moving
> empty pages to the "end". It will release space back to the operating
> system when it has created a chunk of empty pages at the end of the
> file. It will be designed to run in background, and will lock resources
> of the table for as short a time as possible so that it can iteratively
> process the table.
> To reclaim space in the heap, it will scan the heap in page reverse order.
> It will get a short term table lock, process all the rows on a page, and
> then commit that transaction releasing the lock. The commit will be
> optimized like other internal transactions, and will not need to wait
> for a synchonized write. Each row moved, will require all the index
> entries for that row to also be updated. While doing the processing it
> will also take care of processing committed deleted rows. When space
> is free at the end of the table it will be freed back to the operating
> system, using the RandomAccessFile.setLength() interface.
> To reclaim space in the btree, data on pages will be moved rather than
> rows. Data from pages at the end of the file will be moved to free
> smaller numbered pages. Again short term table locks will be required,
> and the operation will look similar to the current btree merge operations
> already implemented. Again when a chunk of pages is free at the end of
> the file, they will be returned to the OS using the same mechanism as
> the heap.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira