[
https://issues.apache.org/jira/browse/CASSANDRA-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15110928#comment-15110928
]
Benjamin Lerer commented on CASSANDRA-8521:
-------------------------------------------
+1
> 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: Sylvain Lebresne
> Priority: Minor
> Fix For: 2.1.x, 2.2.x, 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)
