cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-7394) Optimize CollationController#collectTimeOrderedData() to potentially skip the sstables altogether
Date Mon, 23 Jun 2014 23:51:24 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aleksey Yeschenko updated CASSANDRA-7394:
-----------------------------------------

    Description: As of now, collectTimeOrderedData() will try to read from at least one sstable,
even if the memtable has a row tombstone with a higher timestamp than any max timestamp in
the sstable. If we initiate mostRecentRowTombstone with the value from the memtables and not
Long.MIN_VALUE, reading from the sstables can be avoided entirely in this scenario.  (was:
As of now, collectTimeOrderedData() will try to read from at least one sstable, even if the
request can be fulfilled from the memtable exclusively.

If we initiate mostRecentRowTombstone with the value from the memtables and not Long.MIN_VALUE,
reading from the sstables can be avoided entirely.)

> Optimize CollationController#collectTimeOrderedData() to potentially skip the sstables
altogether
> -------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-7394
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7394
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Aleksey Yeschenko
>            Assignee: Aleksey Yeschenko
>            Priority: Minor
>
> As of now, collectTimeOrderedData() will try to read from at least one sstable, even
if the memtable has a row tombstone with a higher timestamp than any max timestamp in the
sstable. If we initiate mostRecentRowTombstone with the value from the memtables and not Long.MIN_VALUE,
reading from the sstables can be avoided entirely in this scenario.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message