[
https://issues.apache.org/jira/browse/DERBY-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104687#comment-13104687
]
Mike Matrigali commented on DERBY-5356:
---------------------------------------
Some comments on expected behavior and debugging space loss issues:
1) Derby will never automatically give space back to operating system while
deleting rows from a table. It has various methods for reusing this space
eventually for future inserts to the table. The only way to get derby to give
back unused
space in a table and its indexes is to manually call one of the 2 compress
routines: SYSCS_UTIL.SYSCS_COMPRESS_TABLE or SYSCS_INPLACE_COMPRESS_TABLE
2) SYSCS_UTIL.SYSCS_COMPRESS_TABLE is the recommended compress option. It is
guaranteed to reclaim the maximum amount of space possible and return it to the
OS. It will lock the entire table for the duration of the operation,
other threads will automatically wait while the compress procedes.
3) SYSCS_INPLACE_COMPRESS_TABLE can do some of its work concurrently with other
updating processes. But it will request a table level lock in the phase that
returns space to the OS. As with other defragmenters it does not guarantee
to return all space to the OS. It also does no work on indexes as currently
Derby only can shrink an index with a table level lock.
> Tracking for Derby space reclamation issues
> ---------------------------------------------
>
> Key: DERBY-5356
> URL: https://issues.apache.org/jira/browse/DERBY-5356
> Project: Derby
> Issue Type: Task
> Components: Store
> Reporter: Kathey Marsden
>
> This issue is being used to track various Derby space reclamation issues.
> Users have reported the need to do periodic compress due to these issues, so
> opening this issue for centralized tracking of the problem and also to help
> users identify which issue they are hitting and possible work arounds.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
