You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Kunal Khatua (JIRA)" <ji...@apache.org> on 2014/11/20 23:21:34 UTC

[jira] [Created] (DRILL-1762) Apply different levels of parallelization to different phases of the query

Kunal Khatua created DRILL-1762:
-----------------------------------

             Summary: Apply different levels of parallelization to different phases of the query 
                 Key: DRILL-1762
                 URL: https://issues.apache.org/jira/browse/DRILL-1762
             Project: Apache Drill
          Issue Type: Improvement
          Components: Query Planning & Optimization
    Affects Versions: 0.6.0
         Environment: 10-node Drill cluster with TPCH schema (SF100)
OS: RHEL 6.4
cores/node: 32
RAM: 256GB
            Reporter: Kunal Khatua
             Fix For: 0.7.0, Future


When running TPCH queries, we found that setting the planner.max.width_per_node to the maximum number of cores available didn't necessarily improve their runtimes. In almost all queries, setting the property to as low as 12 (on eacch 32-core node), resulted in faster runtimes... which is counter-intuitive.

It is highly possible that the leaf fragments have a larger overhead than many other fragments due to I/O operations, and the high level of parallelization might be causing the entire phase of data scan to be sub-optimal. Based on further investigation, qe might want to split this property  in two... one for leaf fragments (SCANs) and one for the rest of the class of fragments.
e.g TPCH 08 (SF100)
MaxWidth	Runtime (msec)
12		34,650
16		35,216
20		39,482
24		41,694
28		46,579
32		57,207




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)