cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6936) Make all byte representations of types comparable by their unsigned byte representation only
Date Mon, 23 Mar 2015 19:33:54 GMT


Benedict commented on CASSANDRA-6936:

Right. There are three possibilities here: 

1) do nothing
2) make all *common* fields behave this way
3) make all fields behave this way

If we deliver 2 we're likely to get a significant chunk of any performance benefit, but at
the cost of code simplicity. 3 should give us a smidgen more benefit but with simpler code
(which in turn may let us squeeze more out of it, as the code becomes less brittle and easier
to test, so we can push it a little further). There's also an orthogonal discussion of a perhaps
weakening of the requirements for this ticket to just binary prefix comparable, or even _byte_
prefix comparable, rather than _unsigned binary_ prefix comparable. If any such relaxation
makes it appreciable easier and less ugly.

I just want us to investigate as open mindedly as possible how viable going the whole hog
is, and where the ugliness, deprecation or user pain points might be. It's possible it's a
no-go, but I think we may have aborted too early, given the significant upsides.

> Make all byte representations of types comparable by their unsigned byte representation
> --------------------------------------------------------------------------------------------
>                 Key: CASSANDRA-6936
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: 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

View raw message