Before CASSANDRA-1337 [1] (Cassandra 2.1 line) secondary indexes + vnodes
can have very slow performance due to the potentially large number of
splits/nodes sequentially scanned.
=Rob
[1] https://issues.apache.org/jira/browse/CASSANDRA-1337
On 24.10.2013, at 22:00, Petter von Dolwitz (Hem)
wrote:
> I have defined the secondary index on a field that is part of the primary
> key. This should be ok. Maybe you missed the CREATE INDEX bit in my original
> post.
Yes I did - despite actually looking for it :-) Sorry.
Then I am curiou
I have defined the secondary index on a field that is part of the primary
key. This should be ok. Maybe you missed the CREATE INDEX bit in my
original post. I might end up not using secondary indexes but since the
feature is there and I need the functionality I would like to know its
limitations an
On 24.10.2013, at 15:13, Petter von Dolwitz (Hem)
wrote:
> >You cannot use a part in a where clause unless you specify the preceeding
> >parts also.
> But the statement SELECT * FROM mytable WHERE c='myvalue'; works?
>
> What are secondary indexes for then if you can't use them in this way?
>You cannot use a part in a where clause unless you specify the preceeding
parts also.
But the statement SELECT * FROM mytable WHERE c='myvalue'; works?
What are secondary indexes for then if you can't use them in this way?
Forgot to mention that I am on Cassandra 2.0.1
/Petter
2013/10/24 Jan
Petter,
On 24.10.2013, at 14:38, Petter von Dolwitz (Hem)
wrote:
> Hi,
>
> I have a table that (in simplified version) looks like this:
>
> CREATE TABLE mytable (
> a varchar,
> b varchar,
> c varchar
> d timstamp,
> e varchar,
> PRIMARY KEY (a, b, c, d)
> );
>
> CREATE INDEX myt
Hi,
I have a table that (in simplified version) looks like this:
CREATE TABLE mytable (
a varchar,
b varchar,
c varchar
d timstamp,
e varchar,
PRIMARY KEY (a, b, c, d)
);
CREATE INDEX mytable_c_idx ON mytable ( c );
After populating I execute:
SELECT * FROM mytable WHERE c='myvalue
