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
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

Mime
View raw message