> 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
