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-8730) Optimize UUIDType comparisons
Date Mon, 09 Feb 2015 09:14:35 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14311947#comment-14311947
] 

Sylvain Lebresne commented on CASSANDRA-8730:
---------------------------------------------

bq. It looks to me like TimeUUID had the behaviour downgraded to CQL2 only, whereas UUID has
not.

The code inconsistency is likely just a historical accident, but it kind of doesn't matter
much since {{fromString}} will never be called by CQL3 (on a date-string) as CQL3 only accepts
UUID literals for UUID (not string literals, contrarily to CQL2). So as long as we preserve
the behavior for CQL2 until 3.0, we can make the {{fromString}} implementations consistent
by either accepting or rejecting dates in both case (I'd personally go with rejecting dates
as it's dangerous in the first place, but I don't care enough to argument more than that if
someone disagree).

bq. makes TimeUUIDType extend UUIDType

While I don't mind the extension per-se, we have to be careful on the comparison because unfortunately,
TimeUUIDType does *not* compare as UUIDType does. That is, after having compared the timestamps,
UUIDType perform an unsigned comparison of the lsb, while TimeUUIDType uses [ByteBuffer.compareTo|http://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#compareTo(java.nio.ByteBuffer)]
which does a byte-signed comparison. Before someone asks, there is no good excuse for doing
so, it's a pretty old "mistake", but it's not something we can afford to break now.

As an aside, I personally think this should be targeted at 3.0 (it's not a bug fix). Also,
as even subtly changing the comparison would have desastrous consequence, it would be nice
to add a few tests that checks that old and new versions compare the same way (we can't be
exhaustive, but we can get a fair coverage of all code path easily enough).


> Optimize UUIDType comparisons
> -----------------------------
>
>                 Key: CASSANDRA-8730
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8730
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: J.B. Langston
>            Assignee: Benedict
>             Fix For: 2.1.4
>
>
> Compaction is slow on tables using compound keys containing UUIDs due to being CPU bound
by key comparison.  [~benedict] said he sees some easy optimizations that could be made for
UUID comparison.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message