You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2014/09/13 02:09:33 UTC
[jira] [Resolved] (CASSANDRA-7844) Fetching a single static column
requires scanning to the first live CQL row
[ https://issues.apache.org/jira/browse/CASSANDRA-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne resolved CASSANDRA-7844.
-----------------------------------------
Resolution: Not a Problem
As said above, the answer here is to use {{DISTINCT}} so closing this.
> 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
> Priority: Minor
> Labels: perfomance
>
> 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.3.4#6332)