cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Yaskevich (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11075) Consider making SASI the default index implementation
Date Wed, 27 Jan 2016 19:35:39 GMT


Pavel Yaskevich commented on CASSANDRA-11075:

[~slebresne] I think we are still some distance away from making SASI a "default" implementation,
I would like to still be able to do couple of things before considering such a move at least
promote QueryPlan/RangeIterator to the storage layer so different index implementations could
be intermixed. I can also address #1 - SASI currently handles all of the cases of native indexes
expect collections and #2 - SASI doesn't require read-before-write.

If you want you can assign this ticket to me since I'm working on all of this anyway.

> Consider making SASI the default index implementation
> -----------------------------------------------------
>                 Key: CASSANDRA-11075
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
> We now have 2 secondary index implementation in tree: the old native ones and SASI. Moving
forward, that feels like one too much to maintain, especially since it seems that SASI is
an overall better implementation.
> So we should gather enough data to decide if SASI is indeed always better (or at least
sufficiently better than we're convinced no-one would want to stick with the native implementation),
and if that's the case, we should consider making it the default (and ultimately get rid of
the current implementation).
> So first, we should at least:
> # double check that SASI handles all cases that the native implementation handles. A
good start would probably be run all our dtest and utests on a version where SASI is hard-coded
as default.
> # compare the performance of SASI and native indexes. In particular our native indexes,
in all their weaknesses, have the advantage of not doing a read-before-write. Haven't looked
at SASI much so I don't know if it's the case but anyway, we need numbers on both reads and
> Once we have that, if we do decide to make SASI the default, then we need to figure out
what is the upgrade path (and whether we add extra syntax for SASI specific options).

This message was sent by Atlassian JIRA

View raw message