[jira] [Updated] (CASSANDRA-8521) RangeSliceQueryPager may fetch too much data in the first partition
[
https://issues.apache.org/jira/browse/CASSANDRA-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-8521:
--
Fix Version/s: 2.2.x
2.1.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: 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)
[jira] [Updated] (CASSANDRA-8521) RangeSliceQueryPager may fetch too much data in the first partition
[
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)
[jira] [Updated] (CASSANDRA-8521) RangeSliceQueryPager may fetch too much data in the first partition
[
https://issues.apache.org/jira/browse/CASSANDRA-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
T Jake Luciani updated CASSANDRA-8521:
--
Fix Version/s: (was: 2.0.12)
2.0.13
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.1.3, 2.0.13
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)
[jira] [Updated] (CASSANDRA-8521) RangeSliceQueryPager may fetch too much data in the first partition
[
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)
