[
https://issues.apache.org/jira/browse/CASSANDRA-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14613065#comment-14613065
]
Sylvain Lebresne commented on CASSANDRA-9471:
---------------------------------------------
bq. If we choose not to include this feature, it would be better to implement
these directly
How much better? Thinking out loud here, but we're a database, we're dealing
with sorted stuff all the time. So even outside of its use (or not) by
{{Columns}}, having a more capable {{BtreeSet}} implementation, one that can
act more like an efficient sorted list, feels to me like something that would
be useful to have in our tool belt. Meaning by that it sounds from you comments
that the indexability does add much complexity to the
implementation(disclaimer: I haven't looked at the patch) , so if its cost is
really small, maybe it's worth getting the flexibility?
> Columns should be backed by a BTree, not an array
> -------------------------------------------------
>
> Key: CASSANDRA-9471
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9471
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Fix For: 3.0 beta 1
>
>
> Follow up to 8099.
> We have pretty terrible lookup performance as the number of columns grows
> (linear). In at least one location, this results in quadratic performance.
> We don't however want this structure to be either any more expensive to
> build, nor to store. Some small modifications to BTree will permit it to
> serve here, by permitting efficient lookup by index, and calculation _of_
> index for a given key.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
