Support local indexes

[OmerCerrahoglu]

Implement local indexes.

Motivation

Provide better performance for queries with WHERE conditions that fully specify hash keys.

Requirements

A local secondary index is a distributed index. It has the following characteristics:

• It is split and co-located with the data in the individual partitions
• Index update is a local transaction (not distributed across nodes) and is very efficient.
• Index lookup is a local operation (not a distributed txn) and is also very efficient
• Designed for use as index of the data within the partition (i.e. local index). Thus the queries as expected to specify the entire hash partition key(s) to take advantage of this index.
• Queries using the index alone (without specifying the hash partition keys) become full-table (cluster) scan

Initial plan is to implement this as:

• Single indexed column only.
• Can index on keys/elements of a set/list/map

Syntax

Auto-inferred when the index is created using the same hash partition keys as the table.

CREATE INDEX [IF NOT EXISTS] index_name
    ON [keyspace_name.]table_name ( (index_hash_column, ...), index_cluster_column, ... )
    [WITH CLUSTERING ORDER BY (index_cluster_column { ASC | DESC }, ...)]
    [COVERING (covered_column, ...)]
i((hash_columns (from original)), 

Note: we might not want/need to have covering columns, but I guess it can’t hurt (though I am currently not planning on using them in any way, though it shouldn’t be too hard to make use of them: just have the semantic analyzer understand if he index is enough to answer the query)
Note: as the local index already uses the hash keys from the original table as hash keys, we might want not to allow any additional hash keys, but allowing it should not break anything.

Allow additional:

• t(h1 h2 r r2 c1 c2)
• i((h1 h2), c1 r1 r2

[kmuthukk]

moving this to your queue Robert for now.