[ 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)