Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 3 Jul 2013 15:06:20 +0000 (UTC)
From: "Kathey Marsden (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12528312.1319225900904.206241.1372863980606@arcas>
In-Reply-To: <JIRA.12528312.1319225900904@arcas>
References: <JIRA.12528312.1319225900904@arcas>
Subject: [jira] [Commented] (DERBY-5473) Index growth can occur with update
 of ever increasing values
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13699059#comment-13699059 ] 

Kathey Marsden commented on DERBY-5473:
---------------------------------------

Verified this is still an issue on trunk 10.11 but appears worse with more than 500 pages allocated. I don't know if that perhaps is due to using a faster machine.  In general though I have seen several user cases where this paradigm of a small dataset that is getting updated with ever increasing values causes significant growth that can only be mitigated with periodic compress.


> Index growth can occur with update of ever increasing values 
> -------------------------------------------------------------
>
>                 Key: DERBY-5473
>                 URL: https://issues.apache.org/jira/browse/DERBY-5473
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.5.3.2, 10.6.2.3, 10.7.1.4, 10.8.3.0, 10.9.1.0
>            Reporter: Kathey Marsden
>              Labels: derby_triage10_9
>         Attachments: ReproIdxGrowth.java
>
>
> On a table with an  BIGINT Index that is updated quickly with  every increasing values  the index can grow and space not be reclaimed.
> Attaching a reproduction for this issue ReproIdxGrowth.
> The program has a single thread that iteratively updates 5 rows in a table with a time value.
>  PreparedStatement ps = conn.prepareStatement(
>         "UPDATE T SET LAST_SYNC_TIME = ?, NUM_SYNCS = ? WHERE ACCOUNT_ID = ?");
>         ResultSet rs = s.executeQuery("SELECT ACCOUNT_ID, NUM_SYNCS FROM  T");
>         while( rs.next()) {
>             int account = rs.getInt(1);
>             int prevNumSync = rs.getInt(1);
>             ps.setLong(1, new Date().getTime());
>             ps.setInt(2,prevNumSync++);
>             ps.setInt(3, account);
>             ps.executeUpdate();
>         }
> After 50,000 iterations we end up with 150 pages allocated for the just the 5 rows, possibly because it cannot get the table lock to rebalance the tree.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira