The space was reclaimed by the stored proc when the database was "quiet" as I describe it below - that's my definition of true offline mode. This makes me suspect that, before, the stored proc may have tried to X-lock the table a couple of times and may have failed and given up while the database was heavily utilized, but this is just a theory.

However, the most significant issue at the moment related to unreclaimed space seems to be bugs http://issues.apache.org/jira/browse/DERBY-4054 and http://issues.apache.org/jira/browse/DERBY-4055 which have yet to be resolved.


From: T K <sanokistoka@yahoo.com>
To: Derby Discussion <derby-user@db.apache.org>
Sent: Thursday, September 24, 2009 8:14:56 AM
Subject: Re: Horrible performance - how can I reclaim table space?

Yes that's the one I am calling and the space is not reclaimed.


From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
To: Derby Discussion <derby-user@db.apache.org>
Sent: Thursday, September 24, 2009 4:00:52 AM
Subject: Re: Horrible performance - how can I reclaim table space?

T K <sanokistoka@yahoo.com> writes:

> BTW, I have to ask this question: how exactly do we define OFFLINE
> compression? I assume I still bring the database up and call the compression
> stored proc from ij, but no one else connects, correct?

When people talk about offline compression, I think they mean the
SYSCS_UTIL.SYSCS_COMPRESS_TABLE routine, as opposed to
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE. Probably, the use of
online/offline when talking about compression is due to confusion with
the backup terminology.

--
Knut Anders