[
https://issues.apache.org/jira/browse/HBASE-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12683636#action_12683636
]
Jonathan Gray commented on HBASE-1263:
--------------------------------------
Good point, stack. I knew there was something preventing us from doing exotic
comparators :)
> 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.
