[
https://issues.apache.org/jira/browse/PHOENIX-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16640226#comment-16640226
]
ASF GitHub Bot commented on PHOENIX-4594:
-----------------------------------------
Github user BinShi-SecularBird commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/347#discussion_r223111017
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/end2end/ExplainPlanWithStatsEnabledIT.java
---
@@ -853,12 +1032,52 @@ private void testSelectQueriesWithFilters(boolean
useStatsForParallelization) th
assertEquals(100 + i, rs.getInt(1));
i++;
}
+ assertEquals(numRows, i);
info = getByteRowEstimates(conn, sql, binds);
// Depending on the guidepost boundary, this estimate
// can be slightly off. It's called estimate for a reason.
assertEquals((Long) 10L, info.getEstimatedRows());
assertEquals((Long) 720L, info.getEstimatedBytes());
assertTrue(info.getEstimateInfoTs() > 0);
+
+ // Query with multiple scan ranges, and each range's start key
and end key are both between data
+ sql = "SELECT a FROM " + tableName + " WHERE K <= 103 AND K >=
101 OR K <= 108 AND K >= 106";
+ rs = conn.createStatement().executeQuery(sql);
+ i = 0;
+ numRows = 6;
+ int[] result = new int[] { 101, 102, 103, 106, 107, 108 };
+ while (rs.next()) {
+ assertEquals(result[i++], rs.getInt(1));
+ }
+ assertEquals(numRows, i);
+ info = getByteRowEstimates(conn, sql, binds);
+ // Depending on the guidepost boundary, this estimate
+ // can be slightly off. It's called estimate for a reason.
+ assertEquals((Long) 6L, info.getEstimatedRows());
+ assertEquals((Long) 460L, info.getEstimatedBytes());
+ // TODO: the original code before this change will hit the
following assertion. Need to investigate it.
+ // assertTrue(info.getEstimateInfoTs() > 0);
--- End diff --
As the "TODO" in the comment said, this is a new test case I wanted to add
in this change, but it failed. So I reverted all the changes except this new
test case, but it still failed, which means there is problem in the current
code base without any of my change. I commented out the assertion here, but I
opened another JIRA PHOENIX-4914 to track the original problem in the code base.
> Perform binary search on guideposts during query compilation
> ------------------------------------------------------------
>
> Key: PHOENIX-4594
> URL: https://issues.apache.org/jira/browse/PHOENIX-4594
> Project: Phoenix
> Issue Type: Improvement
> Reporter: James Taylor
> Assignee: Bin Shi
> Priority: Major
> Attachments: PHOENIX-4594-0913.patch, PHOENIX-4594_0917.patch,
> PHOENIX-4594_0918.patch
>
>
> If there are many guideposts, performance will suffer during query
> compilation because we do a linear search of the guideposts to find the
> intersection with the scan ranges. Instead, in
> BaseResultIterators.getParallelScans() we should populate an array of
> guideposts and perform a binary search.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
