Benedict created CASSANDRA-11072:
------------------------------------
Summary: Further unify Partition access methods, by removing
searchIterator()
Key: CASSANDRA-11072
URL: https://issues.apache.org/jira/browse/CASSANDRA-11072
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Benedict
Assignee: 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 by:
# 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
(v6.3.4#6332)
