cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-11072) Further unify Partition access methods, by removing searchIterator()
Date Tue, 02 Feb 2016 12:00:44 GMT


Benedict updated CASSANDRA-11072:
    Assignee:     (was: Benedict)

> Further unify Partition access methods, by removing searchIterator()
> --------------------------------------------------------------------
>                 Key: CASSANDRA-11072
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Priority: Minor
>             Fix For: 3.x
> After CASSANDRA-9986, the access paths can be further incrementally simplified.  In particular,
the {{searchIterator}} method is only not trivially replaced in one location, and by removing
it we can simplify the {{SearchIterator}} hierarchy, and merge the {{ClusteringIndexFilter}}
hierarchy, as both use {{Slices}} now.
> In the one remaining location, three approaches are possible (of which I have implemented
two in the attached patch; one in the first diff, one in the last):
> # Apply a transformation to the UnfilteredRowIterator composed of a slices query
> # Call {{getRow}} repeatedly
> # Provide access to an {{unfilteredSearchIterator}} for this method only, since we do
not need to perform the complex filtration for this access path
> These are in decreasing order of costliness (CPU-wise); I don't have a fixed preference.
> This is just a step towards further necessary improvements. IMO, this should be followed
> # Supporting efficient "slicing" of a SearchIterator, so that the internal iteration
of slices within {{unfilteredRowIterator}} is made cheap enough to not warrant a separate
path (this would help all slice queries)
> ## Merging Slice and Clustering hierarchies, perhaps by making Slice an interface and
having Clustering implement it.
> ## Specialising Slices when it contains only Clustering, so that it can implement NavigableSet<Clustering>
(most likely by having it backed by, or extend, BTreeSet)
> ## Thus, saving a lot of shuffling and reconstruction costs around our filters, and reducing
the duplication of concepts in {{ClusteringIndexNamesFilter}}

This message was sent by Atlassian JIRA

View raw message