Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 20 Dec 2016 09:27:58 +0000 (UTC)
From: "Alex Petrov (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13021068.1479282633000.561500.1482226078495@Atlassian.JIRA>
In-Reply-To: <JIRA.13021068.1479282633000@Atlassian.JIRA>
References: <JIRA.13021068.1479282633000@Atlassian.JIRA> <JIRA.13021068.1479282633082@arcas>
Subject: [jira] [Commented] (CASSANDRA-12915) SASI: Index intersection can
 be very inefficient
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 20 Dec 2016 09:28:00 -0000


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

Alex Petrov commented on CASSANDRA-12915:
-----------------------------------------

We've had a short chat on IRC and it was agreed that we'll proceed with the fix for the empty iterator for now. I've suggested several possible alternatives that would help to improve the performance for the use-case right now. 

[~iksaif] would you like to work on a patch for the empty iterator / empty index result or should I do that? Thank you!

> SASI: Index intersection can be very inefficient
> ------------------------------------------------
>
>                 Key: CASSANDRA-12915
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12915
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: sasi
>            Reporter: Corentin Chary
>             Fix For: 3.x
>
>
> It looks like RangeIntersectionIterator.java and be pretty inefficient in some cases. Let's take the following query:
> SELECT data FROM table WHERE index1 = 'foo' AND index2 = 'bar';
> In this case:
> * index1 = 'foo' will match 2 items
> * index2 = 'bar' will match ~300k items
> On my setup, the query will take ~1 sec, most of the time being spent in disk.TokenTree.getTokenAt().
> if I patch RangeIntersectionIterator so that it doesn't try to do the intersection (and effectively only use 'index1') the query will run in a few tenth of milliseconds.
> I see multiple solutions for that:
> * Add a static thresold to avoid the use of the index for the intersection when we know it will be slow. Probably when the range size factor is very small and the range size is big.
> * CASSANDRA-10765


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