Thanks for that clarification, Sylvain. 1. Another clarification: All of the aggregate functions, AVG, SUM, MIN, MAX are in exactly the same boat as COUNT, right?
2. Is the paging for COUNT, et al, done within the coordinator node? 3. Does dedupe on the coordinator node consume memory proportional to the number of rows on all nodes? I mean, you can't dedupe using only partition keys of the coordinator node, right? What I'm wondering is if the usability of COUNT (et al) is memory limited as well as time. Thanks. -- Jack Krupansky On Tue, Apr 19, 2016 at 5:36 AM, Sylvain Lebresne <sylv...@datastax.com> wrote: > >> Accept for relatively small or narrow queries, it seems to have a >> propensity for timing out. >> > > For recent enough version of C*, it shouldn't since it pages internally > (it will be slow and as always be, but it shouldn't time out if some decent > page size is used, which should be the default). I suspect report of it > timeouting are either using old versions (or are using unreasonable paging > size values, but that sounds less likely since I'd assume users would > easily find and fix their error in that case). > > But if the query is timeouting unreasonably for large partition in recent > versions, then it's a bug and a JIRA can be open with reproduction steps. > > -- > Sylvain > >> >
