I think it'd be nice to repeat the use case and behavior for subtotalsSpec here, since it's far away from the top-level docs and the reader might not have seen that. Also please use better grammar here. Pulling those two comments together, how about:
> The subtotals feature allows computation of multiple sub-groupings in a > single query. To use this feature, add a "subtotalsSpec" to your query, which > should be a list of subgroup dimension sets. It should contain the > "outputName" from dimensions in your "dimensions" attribute, in the same > order as they appear in the "dimensions" attribute (although, of course, you > may skip some). For example, consider a groupBy query like this one: We should also mention that it adds 1 to the number of merge buffers you'll need. How about adding this to the "Memory tuning and resource limits" section later on. I believe it's accurate as of the current state of things: > Brokers do not need merge buffers for basic groupBy queries. Queries with > subqueries (using a "query" dataSource _(link to query datasource docs)_) > require one merge buffer if there is a single subquery, or two merge buffers > if there is more than one layer of nested subqueries. Queries with subtotals > _(link to subtotals spec)_ need one merge buffer. These can stack on top of > each other: a groupBy query with multiple layers of nested subqueries, and > that also uses subtotals, will need three merge buffers. > > Historicals and ingestion tasks need one merge buffer for each groupBy query, > unless parallel combination _(link to parallel combine section)_ is enabled, > in which case they need two merge buffers per query. [ Full content available at: https://github.com/apache/incubator-druid/pull/5280 ] This message was relayed via gitbox.apache.org for [email protected]
