[
https://issues.apache.org/jira/browse/CASSANDRA-11075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121779#comment-15121779
]
Jack Krupansky commented on CASSANDRA-11075:
--------------------------------------------
bq. A good start would probably be run all our dtest and utests on a version
where SASI is hard-coded as default.
Maybe it would make sense to introduce a config setting to select the default
indexing. I presume that it would mean the default mode would be SPARSE, which
may make sense for the traditional use cases of Cassandra secondary indexes -
cardinality is not too high and not too low.
Syntax-size, OPTIONS can only be specified when USING is specified. That would
only be an issue if there weren't keywords for all the SASI options. I vaguely
recall [~jbellis] objecting some time ago in some completely unrelated context
about cluttering up the CQL syntax with lots of keywords for options, so it
might make sense to loosen up the CREATE INDEX syntax to allow WITH OPTIONS
even when a class is not specified. The mode might make sense as a keyword, but
then we get to the analyzer class and case sensitivity and the keyword clutter
would start getting out of hand.
> Consider making SASI the default index implementation
> -----------------------------------------------------
>
> Key: CASSANDRA-11075
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11075
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Pavel Yaskevich
>
> 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 writes.
> 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
(v6.3.4#6332)
