drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-5394) Optimize query planning for MapR-DB tables by caching row counts
Date Thu, 30 Mar 2017 01:21:41 GMT

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

ASF GitHub Bot commented on DRILL-5394:
---------------------------------------

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

    https://github.com/apache/drill/pull/802#discussion_r108822541
  
    --- Diff: contrib/format-maprdb/src/main/java/org/apache/drill/exec/store/mapr/db/binary/BinaryTableGroupScan.java
---
    @@ -174,7 +174,7 @@ public MapRDBSubScan getSpecificScan(int minorFragmentId) {
       @Override
       public ScanStats getScanStats() {
         //TODO: look at stats for this.
    -    long rowCount = (long) ((hbaseScanSpec.getFilter() != null ? .5 : 1) * tableStats.getNumRows());
    +    long rowCount = (long) ((hbaseScanSpec.getFilter() != null ? .5 : 1) * hbaseScanSpec.getRowCount());
    --- End diff --
    
    This code change would not be required if we use the alternative approach?


> Optimize query planning for MapR-DB tables by caching row counts
> ----------------------------------------------------------------
>
>                 Key: DRILL-5394
>                 URL: https://issues.apache.org/jira/browse/DRILL-5394
>             Project: Apache Drill
>          Issue Type: Improvement
>          Components: Query Planning & Optimization, Storage - MapRDB
>    Affects Versions: 1.9.0, 1.10.0
>            Reporter: Abhishek Girish
>            Assignee: Padma Penumarthy
>              Labels: MapR-DB-Binary
>             Fix For: 1.11.0
>
>
> On large MapR-DB tables, it was observed that the query planning time was longer than
expected. With DEBUG logs, it was understood that there were multiple calls being made to
get MapR-DB region locations and to fetch total row count for tables.
> {code}
> 2017-02-23 13:59:55,246 [27513143-8718-7a47-a2d4-06850755568a:foreman] DEBUG o.a.d.e.s.m.d.b.BinaryTableGroupScan
- Getting region locations
> 2017-02-23 14:00:05,006 [27513143-8718-7a47-a2d4-06850755568a:foreman] DEBUG o.a.d.e.planner.logical.DrillOptiq
- Function
> ...
> 2017-02-23 14:00:05,031 [27513143-8718-7a47-a2d4-06850755568a:foreman] DEBUG o.a.d.e.s.m.d.b.BinaryTableGroupScan
- Getting region locations
> 2017-02-23 14:00:16,438 [27513143-8718-7a47-a2d4-06850755568a:foreman] DEBUG o.a.d.e.planner.logical.DrillOptiq
- Special
> ...
> 2017-02-23 14:00:16,439 [27513143-8718-7a47-a2d4-06850755568a:foreman] DEBUG o.a.d.e.s.m.d.b.BinaryTableGroupScan
- Getting region locations
> 2017-02-23 14:00:28,479 [27513143-8718-7a47-a2d4-06850755568a:foreman] DEBUG o.a.d.e.planner.logical.DrillOptiq
- Special
> ...
> 2017-02-23 14:00:28,480 [27513143-8718-7a47-a2d4-06850755568a:foreman] DEBUG o.a.d.e.s.m.d.b.BinaryTableGroupScan
- Getting region locations
> 2017-02-23 14:00:42,396 [27513143-8718-7a47-a2d4-06850755568a:foreman] DEBUG o.a.d.e.planner.logical.DrillOptiq
- Special
> ...
> 2017-02-23 14:00:42,397 [27513143-8718-7a47-a2d4-06850755568a:foreman] DEBUG o.a.d.e.s.m.d.b.BinaryTableGroupScan
- Getting region locations
> 2017-02-23 14:00:54,609 [27513143-8718-7a47-a2d4-06850755568a:foreman] DEBUG o.a.d.e.p.s.h.DefaultSqlHandler
- VOLCANO:Physical Planning (49588ms):
> {code}
> We should cache these stats and reuse them where all required during query planning.
This should help reduce query planning time.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message