[jira] [Commented] (CASSANDRA-6936) Make all byte representations of types comparable by their unsigned byte representation only

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

    [ 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)