[
https://issues.apache.org/jira/browse/CASSANDRA-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13948999#comment-13948999
]
Sylvain Lebresne commented on CASSANDRA-6936:
---------------------------------------------
Not too sure what you have in mind here. I don't see how we could achieve that
given that some type (TimeUUID, IntegerType, ...) are intrinsically not
comparable by their bytes representation. And since we do return that
representation to the user, it's not like we can change it to whatever suits
us. Or I guess we could have some conversion of representation when
receiving/sending values but 1) I don't see an easy way to have a bytes
comparable representation of say IntegerType (since it's variable length) and
2) I'm rather uncomfortable with doing complex bit manipulations of the user
data. Besides, there is the custom types (i.e. when users provide their own
AbstractType implementation).
> Make all byte representations of types comparable by their unsigned byte
> representation only
> --------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-6936
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6936
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Labels: performance
> Fix For: 3.0
>
>
> This could be a painful change, but is necessary for implementing a
> trie-based index, and settling for less would be suboptimal; it also should
> make comparisons cheaper all-round, and since comparison operations are
> pretty much the majority of C*'s business, this should be easily felt (see
> CASSANDRA-6553 and CASSANDRA-6934 for an example of some minor changes with
> major performance impacts). No copying/special casing/slicing should mean
> fewer opportunities to introduce performance regressions as well.
> Since I have slated for 3.0 a lot of non-backwards-compatible sstable
> changes, hopefully this shouldn't be too much more of a burden.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
