db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5473) Index growth can occur with update of ever increasing values
Date Wed, 03 Jul 2013 15:06:20 GMT

    [ 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

> 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:,,,,
>            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
>  PreparedStatement ps = conn.prepareStatement(
>         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

View raw message