cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4116) check most recent TS values in SSTables when a row tombstone has already been encountered
Date Tue, 01 May 2012 04:04:08 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13265626#comment-13265626
] 

Jonathan Ellis commented on CASSANDRA-4116:
-------------------------------------------

{code}
.               if (sstable.getMaxTimestamp() < mostRecentRowTombstone)
                    continue;
{code}

For {{collectTimeOrderedData}}, I think that can be a "break" since we're scanning in reverse
chronological order.

For {{collectAllData}}, I think it might be worth making (potentially) two passes: if we find
a deletion marker on the first pass, we should do a second pass, so we can strip out sstables
that we saw the first time before we knew about the marker.  This would improve the deletion
case, without imposing the overhead of a sort or two passes on workloads with no deletes.
                
> check most recent TS values in SSTables when a row tombstone has already been encountered
> -----------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-4116
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4116
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Matthew F. Dennis
>            Assignee: Sam Tunnicliffe
>             Fix For: 1.2
>
>         Attachments: v1-0001-CASSANDRA-4116-After-Row-tombstone-skip-earlier-SSTabl.txt,
v1-0002-CASSANDRA-4116-Set-SSTable-maxTimestamp-correctly-for-.txt
>
>
> once C* comes across a row tombstone, C* should check the TS on the tombstone against
all SSTables.  If the most recent TS in an SST is older than the row tombstone, that entire
SST (or the remainder of it) can be safely ignored.
> There are two drivers for this.
> * avoid checking column values that could not possibly be in the result set
> * avoid OOMing because all the tombstones are temporarily kept in memory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message