From 480e932fdf02ef85ba81181deb865d9977dfed24 Mon Sep 17 00:00:00 2001 From: Justin Borromeo Date: Tue, 26 Mar 2019 14:58:04 -0700 Subject: [PATCH] Checkstyle and doc update --- docs/content/querying/scan-query.md | 3 ++- .../org/apache/druid/query/scan/ScanQueryLimitRowIterator.java | 1 - .../apache/druid/query/scan/ScanQueryRunnerFactoryTest.java | 3 +-- 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/content/querying/scan-query.md b/docs/content/querying/scan-query.md index 1bb67158de9..cd32e51378b 100644 --- a/docs/content/querying/scan-query.md +++ b/docs/content/querying/scan-query.md @@ -158,7 +158,8 @@ The format of the result when resultFormat equals `compactedList`: The Scan query currently supports ordering based on timestamp for non-legacy queries. Note that using time ordering will yield results that do not indicate which segment rows are from (`segmentId` will show up as `null`). Furthermore, time ordering is only supported where the result set limit is less than `druid.query.scan.maxRowsQueuedForOrdering` -rows **or** all segments scanned have fewer than `druid.query.scan.maxSegmentPartitionsOrderedInMemory` partitions. The +rows **or** all segments scanned have fewer than `druid.query.scan.maxSegmentPartitionsOrderedInMemory` partitions. Also, +time ordering is not support for queries issued directly to historicals unless a list of segments is specified. The reasoning behind these limitations is that the implementation of time ordering uses two strategies that can consume too much heap memory if left unbounded. These strategies (listed below) are chosen on a per-Historical basis depending on query result set limit and the number of segments being scanned. diff --git a/processing/src/main/java/org/apache/druid/query/scan/ScanQueryLimitRowIterator.java b/processing/src/main/java/org/apache/druid/query/scan/ScanQueryLimitRowIterator.java index f8c76d03da0..f246d7c5fcf 100644 --- a/processing/src/main/java/org/apache/druid/query/scan/ScanQueryLimitRowIterator.java +++ b/processing/src/main/java/org/apache/druid/query/scan/ScanQueryLimitRowIterator.java @@ -35,7 +35,6 @@ import java.util.ArrayList; import java.util.List; import java.util.Map; - /** * This iterator supports iteration through a Sequence returned by a ScanResultValue QueryRunner. Its behaviour * varies depending on whether the query is returning time-ordered values and whether the CTX_KEY_OUTERMOST flag is diff --git a/processing/src/test/java/org/apache/druid/query/scan/ScanQueryRunnerFactoryTest.java b/processing/src/test/java/org/apache/druid/query/scan/ScanQueryRunnerFactoryTest.java index ef8dc7ff6a0..70cf7709809 100644 --- a/processing/src/test/java/org/apache/druid/query/scan/ScanQueryRunnerFactoryTest.java +++ b/processing/src/test/java/org/apache/druid/query/scan/ScanQueryRunnerFactoryTest.java @@ -40,7 +40,6 @@ import java.util.ArrayList; import java.util.Arrays; import java.util.Collections; import java.util.List; -import java.util.Map; @RunWith(Parameterized.class) @@ -165,7 +164,7 @@ public class ScanQueryRunnerFactoryTest scanResultValues3.add(ScanQueryTestHelper.generateScanResultValue(timestamp, resultFormat, 1)); } - if ( query.getOrder() == ScanQuery.Order.DESCENDING) { + if (query.getOrder() == ScanQuery.Order.DESCENDING) { Collections.reverse(scanResultValues1); Collections.reverse(scanResultValues2); Collections.reverse(scanResultValues3);