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.
