cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6936) Make all byte representations of types comparable by their unsigned byte representation only
Date Thu, 27 Mar 2014 07:23:14 GMT

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

Mime
View raw message