You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Tyler Hobbs (JIRA)" <ji...@apache.org> on 2014/12/19 19:29:13 UTC

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

Tyler Hobbs created CASSANDRA-8521:
--------------------------------------

             Summary: 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: Tyler Hobbs
            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)