db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE question
Date Tue, 08 Nov 2011 17:18:08 GMT
David Zanter wrote:
> The worst case for Derby would be a data distribution of an index which
> 
>     resulted in one row on each leaf.
> 
> 
> By this are you meaning that any "CREATE UNIQUE INDEX"  would be worse 
> case scenario?
> 
no, what I am referring to is the data distribution in the index of 
inserts and deletes.  It depends on a number of factors, but lets assume
1000 keys fit per leaf.

A worst case application would be an application that inserted keys 1 
through 1000, then 1001 through 2000, and then deleted keys 2 through 
1000, and keys 1002 through 2000.  And then continued this process 
forever.  This would leave leafs with a single key and until manual
offline compress was called we would never use the space in those leafs
again.

Because the app never again inserts in the range of the old leafs then
the split space reclamation code never runs.  And because the leafs 
never get empty the merge space reclamation code never gets called.


Mime
View raw message