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 Rick Hillegas <Ri...@Sun.COM> on 2008/12/01 17:02:35 UTC

Re: SYSCS_UTIL.SYSCS_COMPRESS_TABLE

Maybe you could speed up the compression by playing with some of the 
Store parameters, but I'm skeptical. You will probably have to rely on 
mechanisms outside Derby.

Regards,
-Rick

Wei Jiang wrote:
> Thank you for your reply.
>
> Is there anything I can do to make Derby a always-available-database if the compress process takes noticeable time?  
>
>
> --- On Thu, 11/27/08, Knut Anders Hatlen <Kn...@Sun.COM> wrote:
>
>   
>> From: Knut Anders Hatlen <Kn...@Sun.COM>
>> Subject: Re: SYSCS_UTIL.SYSCS_COMPRESS_TABLE
>> To: derby-dev@db.apache.org
>> Cc: _weijiang_@yahoo.com
>> Date: Thursday, November 27, 2008, 4:54 AM
>> Wei Jiang <_w...@yahoo.com> writes:
>>
>>     
>>> Hi,
>>>
>>> Can I use SYSCS_UTIL.SYSCS_COMPRESS_TABLE and
>>> SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE when the
>>>       
>> database is working
>>     
>>> with insert/delete/update?
>>>       
>> Yes, that's supposed to work. SYSCS_COMPRESS_TABLE will
>> obtain an
>> exclusive lock on the table, which means that it will wait
>> until all
>> transactions that are currently accessing the table have
>> released their
>> locks, and it will block new transactions from accessing
>> the table until
>> it has completed the compress operation.
>>
>> -- 
>> Knut Anders
>>     
>
>
>       
>