Re: 1, 2, 3...

SELECT COUNT(*) probably works (with internal paging) on many datasets with enough time and assuming you don’t have any partitions that will kill you. No, it doesn’t count extra replicas / duplicates. The old way to do this (before paging / fetch size) was to use manual paging based on

Re: Efficiently filtering results directly in CS

If you're using C* 3.0 you can probably achieve this with UDFs. http://www.planetcassandra.org/blog/user-defined-functions-in-cassandra-3-0/ On 9 April 2016 at 00:22, Kevin Burton wrote: > Ha.. Yes... C*... I guess I need something like coprocessors in > bigtable. > > On

Re: Efficiently filtering results directly in CS

Ha.. Yes... C*... I guess I need something like coprocessors in bigtable. On Fri, Apr 8, 2016 at 1:49 AM, vincent gromakowski < vincent.gromakow...@gmail.com> wrote: > c* I suppose > > 2016-04-07 19:30 GMT+02:00 Jonathan Haddad : > >> What is CS? >> >> On Thu, Apr 7, 2016

1, 2, 3...

I'm afraid I don't have the solid answer to this obvious question: How do I get a fairly accurate count of (CQL) rows in a Cassandra table? Does SELECT COUNT (*) FROM actually do it? Does it really count (CQL) rows across all nodes and exclude replicated rows? Is there a better/preferred

consistency level ALL?

I was wondering if there are users in this list using consistency level ALL and their reasons for doing so? For example, would the errors for deleting a financial transaction due to an error be reason enough to use consistency level of ALL? Are there other strategies people would use to avoid

Re: disable compaction if all data are read-only?

You still need compaction. Compaction is what organizes your data into levels. Without compaction, every query would have to look at every SSTable. Also, due to commit log rotation, your memtable may get flushed from time to time before it is full, resulting in small SSTables that would benefit

Re: disable compaction if all data are read-only?

I am using leveled strategy. What if my data are 'append-only'? I mean there are always new data but will be never changed once written to cassandra? On Fri, Apr 8, 2016 at 6:33 PM, Pedro Gordo wrote: > Hi Yatong > > My understanding is that if you have a table whichi

Re: all the nost are not reacheable when running massive deletes

It looks like a complex issue that might worth having a close look at your data model, configurations and machines. It is hard to help you from the mailing list. Yet here are some thoughts, some might be irrelevant or wrong, but some other might point you to your issue, hope we will get lucky

Re: disable compaction if all data are read-only?

Hi Yatong My understanding is that if you have a table whichi read-only and hence doesn't receive any writes, then no SSTables will be created, and hence, no compaction will happen. What compaction strategy do you have on your table? Best regards Pedro Gordo On 8 April 2016 at 10:42, Yatong

Re: Returning an UDT from a user defined function (UDF)

Hi Henry, there’s https://issues.apache.org/jira/browse/CASSANDRA-10818 to allow creation of UDTs and tuples. Robert — Robert Stupp @snazy > On Apr 8, 2016, at 07:12, Henry M wrote: > > Whatever I wanted to do

C*2.1 using timestamp with same timestamp

Hello, I try to insert two lines for the same partition with the same timestamp. prmiere the line without TTL. the 2nd line with TTL. As shown in the example below: INSERT INTO tab1 (a,b) VALUES ('YYY','') USING TIMESTAMP 1460088862025940 INSERT INTO tab1 (a,b) VALUES ('YYY','') USING

Re: Efficiently filtering results directly in CS

c* I suppose 2016-04-07 19:30 GMT+02:00 Jonathan Haddad : > What is CS? > > On Thu, Apr 7, 2016 at 10:03 AM Kevin Burton wrote: > >> I have a paging model whereby we stream data from CS by fetching 'pages' >> thereby reading (sequentially) entire