Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.26 as permitted sender)
Message-ID: <32742387.post@talk.nabble.com>
Date: Fri, 28 Oct 2011 22:02:23 -0700 (PDT)
From: Sundar Narayanaswamy <sundar007@yahoo.com>
To: derby-user@db.apache.org
Subject: Re: SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE question
In-Reply-To: <4EAB0D80.504@sbcglobal.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <1319776014.2665.YahooMailNeo@web112411.mail.gq1.yahoo.com>
 <4EAB0D80.504@sbcglobal.net>


I have posted the issue to DERBY-5487. I have also attached the Java test
program. 

The test rows do insert at one end of the primary key and delete the other
end.. Interestingly, I noticed that primary key space is reclaimed if I
reuse the primary keys across the insert-delete loops. But, my application
requires me to use continuously increasing primary keys (not reuse them).


Mike Matrigali wrote:
> 
> Posting your test to a JIRA issue would be best.  It would be 
> interesting to post the space table results after each
> insert/delete/compress iteration (or every 10, ...).
> When do you commit (every row or every 10000)?  Is it multi-threaded? 
> Does your
> test always insert rows at one end of the index and delete them
> from the other end.  If so it may be DERBY-5473 (a runtime issue,
> not a compress table issue).
> 
> 

-- 
View this message in context: http://old.nabble.com/SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE-question-tp32736560p32742387.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.