we should measure the efficiency gains at run time and compare with the additional code complexity.
in a JIT Hotspot, the loss of performance might not be as high as we think. -ryan On Sat, Mar 14, 2009 at 11:14 PM, Jonathan Gray (JIRA) <j...@apache.org>wrote: > > [ > https://issues.apache.org/jira/browse/HBASE-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682131#action_12682131] > > Jonathan Gray commented on HBASE-1263: > -------------------------------------- > > One idea would be to create a special KeyValue comparator that looked at > row and column only and ignored timestamp. > > Stack, it still seems pretty clunky having different KV comparators that > stores must be aware of. At least lots of branchy code at the beginning. > We also talked about potentially allowing descending order or custom > comparators... would there be a "simple" way to make the comparator an > additional and optional family setting? > > > Optimize for single-version families > > ------------------------------------ > > > > Key: HBASE-1263 > > URL: https://issues.apache.org/jira/browse/HBASE-1263 > > Project: Hadoop HBase > > Issue Type: New Feature > > Components: regionserver > > Reporter: Jonathan Gray > > Fix For: 0.20.0 > > > > > > As some of us have been discussing, allowing the client to manually set > the timestamp of a put breaks the general semantics of versioning and I'd > like to see it removed as part of HBASE-880 (a more appropriate place to > debate that). > > However, one trick being used when you don't want the overhead of > versions on a frequently updated column (which are only cleared on > compactions even if set to 1), was to use the same timestamp. Since that > would create an identical key it would just overwrite the value not create a > new version. > > It's a very common use-case, and this hack is being used as part of the > committed increment ops from HBASE-868/HBASE-1252. Rather than making a > special optimization for counters, an optimization on single-version > families that never stores more than one version of a column. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
