> This would seem to conflict with the advice to only use secondary indexes on
> fields with low cardinality, not high cardinality. I guess low cardinality is
> good, as long as it isn't /too/ low?
My concern is seeing people in the wild create secondary indexes with low
cardinality that genera
Couple of questions about the test setup:
- are you running the tests in parallel (via threadCount in surefire
or failsafe for example?)
- is the instance of cassandra per-class for per jvm? (or is fork=true?)
On Sun, Jul 14, 2013 at 5:52 PM, Tristan Seligmann
wrote:
> On Mon, Jul 15, 2013 at 12
On Mon, Jul 15, 2013 at 12:26 AM, aaron morton wrote:
> Aaron Morton can confirm but I think one problem could be that to create
> an index on a field with small number of possible values is not good.
>
> Yes.
> In cassandra each value in the index becomes a single row in the internal
> secondary
> Aaron Morton can confirm but I think one problem could be that to create an
> index on a field with small number of possible values is not good.
Yes.
In cassandra each value in the index becomes a single row in the internal
secondary index CF. You will end up with a huge row for all the values
Aaron Morton can confirm but I think one problem could be that to create an
index on a field with small number of possible values is not good.
Regards,
Shahab
On Sat, Jul 13, 2013 at 9:14 AM, Tristan Seligmann
wrote:
> On Fri, Jul 12, 2013 at 10:38 AM, aaron morton wrote:
>
>> CREATE INDEX ON c
On Fri, Jul 12, 2013 at 10:38 AM, aaron morton wrote:
> CREATE INDEX ON conv_msgdata_by_participant_cql(msgReadFlag);
>
> On general this is a bad idea in Cassandra (also in a relational DB IMHO).
> You will get poor performance from it.
>
Could you elaborate on why this is a bad idea?
--
mi
> The “ALLOW FILTERING” clause also has no effect.
You only need that when the WHERE clause contains predicates for columns that
are not part of the primary key.
> CREATE INDEX ON conv_msgdata_by_participant_cql(msgReadFlag);
On general this is a bad idea in Cassandra (also in a relational DB IM
Hi,
I've been tearing my hair out trying to figure out why this
query fails. In fact, it only fails on machines with slower CPUs and after
having previously run some other junit tests. I'm running junits to an
embedded Cassandra server, which works well in pretty much all other
