[jira] [Created] (CASSANDRA-7844) Fetching a single static column requires scanning to the first live CQL row

["Nicolas Favre-Felix (JIRA)" <ji...@apache.org>]

Nicolas Favre-Felix created CASSANDRA-7844:
----------------------------------------------

             Summary: Fetching a single static column requires scanning to the first live CQL row
                 Key: CASSANDRA-7844
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7844
             Project: Cassandra
          Issue Type: Bug
          Components: Core
            Reporter: Nicolas Favre-Felix


Reading a single static column seems to do more work than needed, scanning the partition until the first live CQL row before returning a value.

As I understand, static columns are stored separately from clustered rows (see CASSANDRA-6956 for an issue that arised from this storage model). Nevertheless, Cassandra doesn't optimize for the case where only static columns and partition key dimensions are retrieved.

Selecting a static column on its own is possible:

{code}
> create table friends (user text, next_id int static, friend_id int, email text, primary key(user,friend_id));
> insert into friends (user, next_id) values ('user1', 1);
> select * from friends where user = 'user1';

 user  | friend_id | next_id | email
-------+-----------+---------+-------
 user1 |      null |       1 |  null

(1 rows)
{code}


Let's insert and delete some clustered data:

{code}
> insert into friends (user, next_id, friend_id, email) values ('user1', 2, 1, 'abc@foo');
> insert into friends (user, next_id, friend_id, email) values ('user1', 3, 2, 'def@foo');
> insert into friends (user, next_id, friend_id, email) values ('user1', 4, 3, 'ghi@foo');
> select * from friends where user = 'user1';

 user  | friend_id | next_id | email
-------+-----------+---------+---------
 user1 |         1 |       4 | abc@foo
 user1 |         2 |       4 | def@foo
 user1 |         3 |       4 | ghi@foo

(3 rows)


> delete from friends where user = 'user1' and friend_id = 1;
> delete from friends where user = 'user1' and friend_id = 2;
> delete from friends where user = 'user1' and friend_id = 3;
{code}


And then fetch the static column again:

{code}
> TRACING ON
Now tracing requests.
> select next_id from friends where user = 'user1' limit 1;

 next_id
---------
       4

(1 rows)


Tracing session: 597cc970-2e27-11e4-932f-c551d8e65d14

 activity                                                                  | timestamp    | source    | source_elapsed
---------------------------------------------------------------------------+--------------+-----------+----------------
                                                        execute_cql3_query | 13:18:46,792 | 127.0.0.1 |              0
         Parsing SELECT next_id from friends where user = 'user1' LIMIT 1; | 13:18:46,792 | 127.0.0.1 |             59
                                                       Preparing statement | 13:18:46,792 | 127.0.0.1 |            125
                               Executing single-partition query on friends | 13:18:46,792 | 127.0.0.1 |            357
                                              Acquiring sstable references | 13:18:46,792 | 127.0.0.1 |            369
                                               Merging memtable tombstones | 13:18:46,792 | 127.0.0.1 |            381
 Skipped 0/0 non-slice-intersecting sstables, included 0 due to tombstones | 13:18:46,792 | 127.0.0.1 |            445
                                Merging data from memtables and 0 sstables | 13:18:46,792 | 127.0.0.1 |            460
                                        Read 1 live and 6 tombstoned cells | 13:18:46,792 | 127.0.0.1 |            504
                                                          Request complete | 13:18:46,792 | 127.0.0.1 |            711
{code}
    
    
We went over tombstones instead of returning the static column immediately.

Is this possibly related to CASSANDRA-7085?



--
This message was sent by Atlassian JIRA
(v6.2#6252)