cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-5373) Collection of min/max timestamp during compaction seems unnecessarily imprecise
Date Thu, 21 Mar 2013 18:01:20 GMT
Sylvain Lebresne created CASSANDRA-5373:
-------------------------------------------

             Summary: Collection of min/max timestamp during compaction seems unnecessarily
imprecise
                 Key: CASSANDRA-5373
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5373
             Project: Cassandra
          Issue Type: Improvement
            Reporter: Sylvain Lebresne
            Assignee: Sylvain Lebresne
            Priority: Minor


In {{ColumnFamilyStore.createCompactionWriter()}} we have (for each sstable compacted):
{noformat}
           sstableMetadataCollector.updateMinTimestamp(sstable.getMinTimestamp());
           sstableMetadataCollector.updateMaxTimestamp(sstable.getMaxTimestamp());

{noformat}

This means that the compacted sstable min (resp. max) timestamp can't be bigger (resp. smaller)
than the min (resp. max) timestamp of the sstable used to create it. However, not only can't
I find a reason for that, but I think this makes collecting very imprecise (not to say broken).
Namely, we'll keep the lowest timestamp we have ever seen, which doesn't take overwrite into
account. This also doesn't take deletes into account, and perhaps more importantly, this doesn't
take LCS into account.

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