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

Aleksey Yeschenko updated CASSANDRA-8521:
-----------------------------------------
    Fix Version/s:     (was: 2.1.x)
                   3.x

> RangeSliceQueryPager may fetch too much data in the first partition
> -------------------------------------------------------------------
>
>                 Key: CASSANDRA-8521
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8521
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Tyler Hobbs
>            Assignee: Benjamin Lerer
>            Priority: Minor
>             Fix For: 3.x
>
>
> As described in CASSANDRA-8087, it looks like RangeSliceQueryPager may fetch 
> more than it needs to in the first partition:
> {quote}
> when we actually query the underlying partition, the slice filter count might 
> be a lot more than what we care for (it could be Integer.MAX_VALUE if there 
> wasn't any LIMIT on the statement in the first place) and if that's the case, 
> we will read a lot more than we should. This will be only true for the first 
> partition, because after that we will update the SliceQueryFilter at the end 
> of the loop of CFS.filter(), but still, it's potentially inefficient for that 
> that first partition and might even end up blowing up the heap if the 
> partition is big, which defeats the purpose of paging. I'll note that 
> provided we don't blow up the heap then the resultSet returned to the user 
> will be fine since we'll trim it in SelectStatement, but it's still a bug 
> (provided I'm not missing something).
> {quote}



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

Reply via email to