cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1600) Merge get_indexed_slices with get_range_slices
Date Fri, 15 Oct 2010 05:09:30 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921230#action_12921230
] 

Stu Hood commented on CASSANDRA-1600:
-------------------------------------

> applies row_filter during a row scan
I'm willing to say that this should be "considered harmful". Without a toggle to disable the
RPC_TIMEOUT, we'd be setting people up for their unbounded scans to succeed in testing, and
then cause cascading failures in production by going into retry loops that scan (70 MB * 10s)
of data before timing out.

Indexed scans are safe, in that the worst case is that you don't match anything in your index,
and you have to get empty results from every node in your cluster. Empty results are cheap.

> Merge get_indexed_slices with get_range_slices
> ----------------------------------------------
>
>                 Key: CASSANDRA-1600
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API
>            Reporter: Stu Hood
>             Fix For: 0.7.0
>
>         Attachments: 0001-Add-optional-IndexClause-to-KeyRange-and-serialize-w.patch,
0002-Drop-the-IndexClause.count-parameter.patch, 0003-Execute-RangeSliceCommands-using-scan-when-an-IndexC.patch,
0004-Remove-get_indexed_slices-method.patch, 0005-Update-system-tests-to-use-get_range_slices.patch,
0006-Remove-start_key-from-IndexClause-for-the-start_key-.patch, 0007-Respect-end_key-for-filtered-queries.patch
>
>
> From a comment on 1157:
> {quote}
> IndexClause only has a start key for get_indexed_slices, but it would seem that the reasoning
behind using 'KeyRange' for get_range_slices applies there as well, since if you know the
range you care about in the primary index, you don't want to continue scanning until you exhaust
'count' (or the cluster).
> Since it would appear that get_indexed_slices would benefit from a KeyRange, why not
smash get_(range|indexed)_slices together, and make IndexClause an optional field on KeyRange?
> {quote}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message