This is an automated email from the ASF dual-hosted git repository.
jihoonson pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/druid-website.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new 2585a08 Latest changes for 0.18.0
new 4189007 Merge pull request #80 from jihoonson/0.18.0-docs-update2
2585a08 is described below
commit 2585a086545cbb13d87336e15b9f08d9ada96ebc
Author: Jihoon Son <[email protected]>
AuthorDate: Thu Apr 16 14:26:20 2020 -0700
Latest changes for 0.18.0
---
docs/0.18.0/querying/groupbyquery.html | 2 +-
docs/latest/querying/groupbyquery.html | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/0.18.0/querying/groupbyquery.html
b/docs/0.18.0/querying/groupbyquery.html
index acf7958..18d13f9 100644
--- a/docs/0.18.0/querying/groupbyquery.html
+++ b/docs/0.18.0/querying/groupbyquery.html
@@ -433,7 +433,7 @@ strategy perform the outer query on the Broker in a
single-threaded fashion.</p>
<tr><td><code>druid.query.groupBy.forceHashAggregation</code></td><td>Force to
use hash-based aggregation.</td><td>false</td></tr>
<tr><td><code>druid.query.groupBy.intermediateCombineDegree</code></td><td>Number
of intermediate nodes combined together in the combining tree. Higher degrees
will need less threads which might be helpful to improve the query performance
by reducing the overhead of too many threads if the server has sufficiently
powerful cpu cores.</td><td>8</td></tr>
<tr><td><code>druid.query.groupBy.numParallelCombineThreads</code></td><td>Hint
for the number of parallel combining threads. This should be larger than 1 to
turn on the parallel combining feature. The actual number of threads used for
parallel combining is
min(<code>druid.query.groupBy.numParallelCombineThreads</code>,
<code>druid.processing.numThreads</code>).</td><td>1 (disabled)</td></tr>
-<tr><td><code>druid.query.groupBy.applyLimitPushDownToSegment</code></td><td>If
Broker pushes limit down to queryable nodes (historicals, peons) then limit
results during segment scan.</td><td>true (enabled)</td></tr>
+<tr><td><code>druid.query.groupBy.applyLimitPushDownToSegment</code></td><td>If
Broker pushes limit down to queryable data server (historicals, peons) then
limit results during segment scan. If typically there are a large number of
segments taking part in a query on a data server, this setting may
counterintuitively reduce performance if enabled.</td><td>false
(disabled)</td></tr>
</tbody>
</table>
<p>Supported query contexts:</p>
diff --git a/docs/latest/querying/groupbyquery.html
b/docs/latest/querying/groupbyquery.html
index 3739a74..957f6c7 100644
--- a/docs/latest/querying/groupbyquery.html
+++ b/docs/latest/querying/groupbyquery.html
@@ -433,7 +433,7 @@ strategy perform the outer query on the Broker in a
single-threaded fashion.</p>
<tr><td><code>druid.query.groupBy.forceHashAggregation</code></td><td>Force to
use hash-based aggregation.</td><td>false</td></tr>
<tr><td><code>druid.query.groupBy.intermediateCombineDegree</code></td><td>Number
of intermediate nodes combined together in the combining tree. Higher degrees
will need less threads which might be helpful to improve the query performance
by reducing the overhead of too many threads if the server has sufficiently
powerful cpu cores.</td><td>8</td></tr>
<tr><td><code>druid.query.groupBy.numParallelCombineThreads</code></td><td>Hint
for the number of parallel combining threads. This should be larger than 1 to
turn on the parallel combining feature. The actual number of threads used for
parallel combining is
min(<code>druid.query.groupBy.numParallelCombineThreads</code>,
<code>druid.processing.numThreads</code>).</td><td>1 (disabled)</td></tr>
-<tr><td><code>druid.query.groupBy.applyLimitPushDownToSegment</code></td><td>If
Broker pushes limit down to queryable nodes (historicals, peons) then limit
results during segment scan.</td><td>true (enabled)</td></tr>
+<tr><td><code>druid.query.groupBy.applyLimitPushDownToSegment</code></td><td>If
Broker pushes limit down to queryable data server (historicals, peons) then
limit results during segment scan. If typically there are a large number of
segments taking part in a query on a data server, this setting may
counterintuitively reduce performance if enabled.</td><td>false
(disabled)</td></tr>
</tbody>
</table>
<p>Supported query contexts:</p>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
