[ 
https://issues.apache.org/jira/browse/DERBY-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557065#action_12557065
 ] 

quartz commented on DERBY-1068:
-------------------------------

> Derby does reuse space in the table when subsequent inserts come in.
> The level of reuse tends to be when a whole page of data becomes deleted.

This is not true. From the doc of SYSCS_UTIL.SYSCS_COMPRESS_TABLE, as is:
"Typically, unused allocated space exists when a large amount of data is 
deleted from a table, or indexes are updated. By default, Derby does not return 
unused space to the operating system."


Normal tests tables show the seg0/ folder takes about 40 MB.
The crashed customer where the compress isn't working had a seg0/ folder of 
about 480 MB!
I must call a compress periodically.

In place or not, it has to be completely safe, concurrent or not. What I meant 
is that issuing an insert while compressing shouldn't result in either of the 
statement failing.


> change of store contract: online compress operations should not share any 
> locks with user transactions
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1068
>                 URL: https://issues.apache.org/jira/browse/DERBY-1068
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>            Reporter: Andreas Korneliussen
>            Assignee: Mike Matrigali
>            Priority: Minor
>
> Propose to add the following to the store contract:
> * truncate and compress requires exclusive table locking
> * the truncate, purge and compress operations do not share any locks with 
> user transactions 
> Currently the store implementation allows users to share locks in truncate 
> and possibly purge.
> This request is driven by:
> http://www.nabble.com/conflict-detection-strategies-t1120376.html#a2938142
> and:
> http://www.nabble.com/RowLocation-contract-from-storage-engine-t1142235.html#a2994156

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to