Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 27 Mar 2014 00:42:14 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12703776.1395857932463.13287.1395880934839@arcas>
In-Reply-To: <JIRA.12703776.1395857932463@arcas>
References: <JIRA.12703776.1395857932463@arcas>
Subject: [jira] [Commented] (CASSANDRA-6933) Optimise Read Comparison Costs
 in collectTimeOrderedData
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jonathan Ellis commented on CASSANDRA-6933:
-------------------------------------------

I'm pretty sure "keep track of how many keys were skipped to satisfy last lookup" is a premature optimization.  bsearch is logarithmic after all, so it doesn't take a whole lot of "oops we were wrong, try again" to eat up the gains.

> Optimise Read Comparison Costs in collectTimeOrderedData
> --------------------------------------------------------
>
>                 Key: CASSANDRA-6933
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6933
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Minor
>              Labels: performance
>             Fix For: 2.1
>
>
> Introduce a new SearchIterator construct, which can be obtained from a ColumnFamily, which permits efficiently iterating a subset of the cells in ascending order. Essentially, it saves the previously visited position and searches from there, but also tries to avoid searching the whole remaining space if possible.


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