[
https://issues.apache.org/jira/browse/HBASE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14093578#comment-14093578
]
Lars Hofhansl commented on HBASE-10247:
---------------------------------------
Here's an interesting question: What should happen with TS specific deletes
when the client does not set the ts? If we allow to data deletes into the
future, we'll have won nothing.
If we disallow client set timestamps for deletes, then we can no longer target
a specific version for delete (for deleteColumn), nor target only some versions
for delete (deleteColumns and deleteFamily). So if the server sets the TS or
SeqId, we can no longer delete specific version, not can we delete only some
columns in the past.
I suppose we could allow timestamp that are strictly older than the next
timestamp the server would hand out...?
> Client promises about timestamps
> --------------------------------
>
> Key: HBASE-10247
> URL: https://issues.apache.org/jira/browse/HBASE-10247
> Project: HBase
> Issue Type: Brainstorming
> Reporter: Lars Hofhansl
> Priority: Minor
> Fix For: 0.99.0, 2.0.0
>
> Attachments: 10247.txt
>
>
> This is to start a discussion about timestamp promises declared per table of
> CF.
> For example if a client promises only monotonically increasing timestamps (or
> no custom set timestamps) and VERSIONS=1, we can aggressively and easily
> remove old versions of the same row/fam/col from the memstore before we
> flush, just by supplying a comparator that ignores the timestamp (i.e. two KV
> just differing by TS would be considered equal).
> That would increase the performance of counters significantly.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
