cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8730) Optimize UUIDType comparisons
Date Mon, 09 Feb 2015 09:14:35 GMT


Sylvain Lebresne commented on CASSANDRA-8730:

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

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|]
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:
>             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

View raw message