I guess I misspoke, sorry. It is true that count() as any other query is still governed by the read timeout and any count that has to process a lot of data will take a long time and will require a high timeout set to not timeout (true of every aggregation query as it happens).
I guess I responded too quickly to "if you want a reliable count" because for a while count() was actually OOMing for large partition/queries, which is not true anymore, and my brain made a connection that wasn't there since that's not what Kurt said. So sorry for the noise. On Mon, Feb 20, 2017 at 2:47 PM, Benjamin Roth <benjamin.r...@jaumo.com> wrote: > +1 I also encountered timeouts many many times (using DS DevCenter). > Roughly this occured when count(*) > 1.000.000 > > 2017-02-20 14:42 GMT+01:00 Edward Capriolo <edlinuxg...@gmail.com>: > >> Seems worth it to file a bug since some here are under the impression it >> almost always works and others are under the impression it almost never >> works. >> >> On Friday, February 17, 2017, kurt greaves <k...@instaclustr.com> wrote: >> >>> really... well that's good to know. it still almost never works though. >>> i guess every time I've seen it it must have timed out due to tombstones. >>> >>> On 17 Feb. 2017 22:06, "Sylvain Lebresne" <sylv...@datastax.com> wrote: >>> >>> On Fri, Feb 17, 2017 at 11:54 AM, kurt greaves <k...@instaclustr.com> >>> wrote: >>> >>>> if you want a reliable count, you should use spark. performing a count >>>> (*) will inevitably fail unless you make your server read timeouts and >>>> tombstone fail thresholds ridiculous >>>> >>> >>> That's just not true. count(*) is paged internally so while it is not >>> particular fast, it shouldn't require bumping neither the read timeout nor >>> the tombstone fail threshold in any way to work. >>> >>> In that case, it seems the partition does have many tombstones (more >>> than live rows) and so the tombstone threshold is doing its job of warning >>> about it. >>> >>> >>>> >>>> On 17 Feb. 2017 04:34, "Jan" <j...@dafuer.de> wrote: >>>> >>>>> Hi, >>>>> >>>>> could you post the output of nodetool cfstats for the table? >>>>> >>>>> Cheers, >>>>> >>>>> Jan >>>>> >>>>> Am 16.02.2017 um 17:00 schrieb Selvam Raman: >>>>> >>>>> I am not getting count as result. Where i keep on getting n number of >>>>> results below. >>>>> >>>>> Read 100 live rows and 1423 tombstone cells for query SELECT * FROM >>>>> keysace.table WHERE token(id) > token(test:ODP0144-0883E-022R-002/047-052) >>>>> LIMIT 100 (see tombstone_warn_threshold) >>>>> >>>>> On Thu, Feb 16, 2017 at 12:37 PM, Jan Kesten <j...@dafuer.de> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> do you got a result finally? >>>>>> >>>>>> Those messages are simply warnings telling you that c* had to read >>>>>> many tombstones while processing your query - rows that are deleted but >>>>>> not >>>>>> garbage collected/compacted. This warning gives you some explanation why >>>>>> things might be much slower than expected because per 100 rows that count >>>>>> c* had to read about 15 times rows that were deleted already. >>>>>> >>>>>> Apart from that, count(*) is almost always slow - and there is a >>>>>> default limit of 10.000 rows in a result. >>>>>> >>>>>> Do you really need the actual live count? To get a idea you can >>>>>> always look at nodetool cfstats (but those numbers also contain deleted >>>>>> rows). >>>>>> >>>>>> >>>>>> Am 16.02.2017 um 13:18 schrieb Selvam Raman: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I want to know the total records count in table. >>>>>> >>>>>> I fired the below query: >>>>>> select count(*) from tablename; >>>>>> >>>>>> and i have got the below output >>>>>> >>>>>> Read 100 live rows and 1423 tombstone cells for query SELECT * FROM >>>>>> keysace.table WHERE token(id) > >>>>>> token(test:ODP0144-0883E-022R-002/047-052) >>>>>> LIMIT 100 (see tombstone_warn_threshold) >>>>>> >>>>>> Read 100 live rows and 1435 tombstone cells for query SELECT * FROM >>>>>> keysace.table WHERE token(id) > token(test:2565-AMK-2) LIMIT 100 (see >>>>>> tombstone_warn_threshold) >>>>>> >>>>>> Read 96 live rows and 1385 tombstone cells for query SELECT * FROM >>>>>> keysace.table WHERE token(id) > token(test:-2220-UV033/04) LIMIT 100 (see >>>>>> tombstone_warn_threshold). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Can you please help me to get the total count of the table. >>>>>> >>>>>> -- >>>>>> Selvam Raman >>>>>> "லஞ்சம் தவிர்த்து நெஞ்சம் நிமிர்த்து" >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Selvam Raman >>>>> "லஞ்சம் தவிர்த்து நெஞ்சம் நிமிர்த்து" >>>>> >>>>> >>>>> >>> >>> >> >> -- >> Sorry this was sent from mobile. Will do less grammar and spell check >> than usual. >> > > > > -- > Benjamin Roth > Prokurist > > Jaumo GmbH · www.jaumo.com > Wehrstraße 46 · 73035 Göppingen · Germany > Phone +49 7161 304880-6 <+49%207161%203048806> · Fax +49 7161 304880-1 > <+49%207161%203048801> > AG Ulm · HRB 731058 · Managing Director: Jens Kammerer >
