[ https://issues.apache.org/jira/browse/DRILL-5394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15948219#comment-15948219 ]
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_r108821978 --- Diff: contrib/storage-hbase/src/main/java/org/apache/drill/exec/store/hbase/HBaseScanSpec.java --- @@ -76,6 +78,10 @@ public String getTableName() { return stopRow == null ? HConstants.EMPTY_START_ROW : stopRow; } + public long getRowCount() { return rowCount; } + + public void setRowCount(long numRowCount) { rowCount = numRowCount; } --- End diff -- Should the ScanSpec be mutable since it serves a specification? I looked at other ScanSpecs but none seem to set ScanSpec members. Maybe all the members should be final and initialized via the constructor? > 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)