[
https://issues.apache.org/jira/browse/CASSANDRA-11072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15119337#comment-15119337
]
Benedict commented on CASSANDRA-11072:
--------------------------------------
So, for fun and as a parting gift, I decided to implement the slicing of a
{{SearchIterator}}, as this is pretty straight forward. I've gone ahead and
used this functionality in the {{AbstractBTreePartition}} so that iteration of
slices is more efficient, always continuing from where the prior iteration left
off.
This permits the remaining location that benefited from a search iterator to
just use a sliced {{UnfilteredRowIterator}}.
it also makes the RangeTombstoneList and Slices both in more obvious need of
being improved, as the algorithmic complexity of the their use is meaningfully
worse. In a healthy data model they should be much smaller, however.
Obviously, feel free to utilise/discard as you wish.
> 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)
