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] [Commented] (CASSANDRA-8914) Don't lookup maxPurgeableTimestamp unless we need to
Date Fri, 20 Mar 2015 16:06:40 GMT

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

Sylvain Lebresne commented on CASSANDRA-8914:
---------------------------------------------

+1 with 2 minor nits:
* We can replace {{maxRowTombstone != DeletionTime.LIVE}} by {{!maxRowTombstone.isLive()}}.
Is _think_ both are always equivalent but I'm not 200% sure (that we never create a "live"
DeletionTime without using {{DeletionTime.LIVE}}). Not that it would matter tremendously in
this case ...
* In {{getReduced}}, we can actually assume there is a cell before we've called removeDeleted
(the existing code does assume it). So we can simplify slightly by removing the first {{iter.hasNext()}}
condition.

> Don't lookup maxPurgeableTimestamp unless we need to
> ----------------------------------------------------
>
>                 Key: CASSANDRA-8914
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8914
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Marcus Eriksson
>            Assignee: Marcus Eriksson
>             Fix For: 2.1.4
>
>         Attachments: 0001-only-get-maxPurgableTimestamp-if-we-know-there-are-t.patch,
8914-v2.patch
>
>
> Currently we look up the maxPurgeableTimestamp in LazilyCompactedRow constructor, we
should only do that if we have to (ie, if we know there is a tombstone to possibly drop)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message