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] [Created] (CASSANDRA-11834) Don't compute expensive MaxPurgeableTimestamp until we've verified there's an expired tombstone
Date Wed, 18 May 2016 16:32:13 GMT
Jonathan Ellis created CASSANDRA-11834:
------------------------------------------

             Summary: Don't compute expensive MaxPurgeableTimestamp until we've verified there's
an expired tombstone
                 Key: CASSANDRA-11834
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11834
             Project: Cassandra
          Issue Type: Bug
          Components: Compaction
            Reporter: Jonathan Ellis
             Fix For: 2.1.15


In LCR's get reduced, we currently do this:

{code}
                if (t.timestamp() < getMaxPurgeableTimestamp() && t.data.isGcAble(controller.gcBefore))
{code}

Should call the expensive getMaxPurgeableTimestamp only after we have called the cheap isGcAble.

Marking this as a bug since it can cause pathological performance problems (CASSANDRA-11831).

Have verified that this is not a problem in 3.0 (CompactionIterator does the check in the
correct order).



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

Mime
View raw message