[jira] [Updated] (CASSANDRA-8521) RangeSliceQueryPager may fetch too much data in the first partition

["Tyler Hobbs (JIRA)" <ji...@apache.org>]

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

Tyler Hobbs updated CASSANDRA-8521:
-----------------------------------
    Assignee: Benjamin Lerer  (was: Tyler Hobbs)

> 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
>          Components: Core
>            Reporter: Tyler Hobbs
>            Assignee: Benjamin Lerer
>            Priority: Minor
>             Fix For: 2.0.12, 2.1.3
>
>
> 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)