You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@phoenix.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/10/01 21:29:00 UTC

[jira] [Commented] (PHOENIX-4594) Perform binary search on guideposts during query compilation

    [ https://issues.apache.org/jira/browse/PHOENIX-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634654#comment-16634654 ] 

ASF GitHub Bot commented on PHOENIX-4594:
-----------------------------------------

Github user twdsilva commented on a diff in the pull request:

    https://github.com/apache/phoenix/pull/347#discussion_r221142871
  
    --- 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 --
    
    Why does this assert fail now?


> 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)