Configuring the MPP engine from the Query Execution Plan Viewer

Click on the PARALEL_FETCH on the left hand side to display a detailed Query Execution Plan on the right hand side. In case PARALLEL _FETCH did not happen, click on SELECT, to investigate the reason. The reason explained in the right-pane will help you tune your settings. Refer the section Considerations for using MPP Engine for a list of things to consider while using the MPP Engine.

SQL: SELECT `R_1`.`nation`,`R_1`.`o_year`,SUM(1) AS `sum_profit` FROM (SELECT `R_3`.`nation`,EXTRACT(YEAR FROM `R_5`.`o_orderdate`) AS `o_year` FROM `ciscodv.Q-1919832149200026`.`R_3` INNER JOIN `ciscodv.Q-1919832149200026`.`R_4` ON `R_3`.`n_nationkey` = `R_4`.`s_nationkey` INNER JOIN `ciscodv.Q-1919832149200026`.`R_5` ON `R_4`.`s_suppkey` = `R_5`.`l_suppkey` INNER JOIN `ciscodv.Q-1919832149200026`.`R_2` ON `R_5`.`l_partkey` = `R_2`.`ps_partkey` AND `R_5`.`l_suppkey` = `R_2`.`ps_suppkey`) `R_1` GROUP BY `R_1`.`nation`,`R_1`.`o_year` ORDER BY `R_1`.`nation` NULLS FIRST,`R_1`.`o_year` DESC NULLS LAST

R_5 - SQL: SELECT "C##TPCH10"."H_PART"."P_PARTKEY","C##TPCH10"."H_ORDER"."O_ORDERDATE","C##TPCH10"."H_LINEITEM"."L_PARTKEY","C##TPCH10"."H_LINEITEM"."L_SUPPKEY" FROM "C##TPCH10"."H_PART" INNER JOIN ("C##TPCH10"."H_LINEITEM" INNER JOIN "C##TPCH10"."H_ORDER" ON "C##TPCH10"."H_LINEITEM"."L_ORDERKEY" = "C##TPCH10"."H_ORDER"."O_ORDERKEY") ON "C##TPCH10"."H_PART"."P_NAME" LIKE '%dodger%' AND "C##TPCH10"."H_PART"."P_PARTKEY" = "C##TPCH10"."H_LINEITEM"."L_PARTKEY"

Field	Description
Estimated Rows Returned	The estimated number of rows returned for the whole query. Notice that in the above example, multiple data sources are being used in the query and the estimated number of rows returned is 8M.
SQL	The SQL query that is being executed. Notice that in the above example, the topmost query is the main query which is decomposed into partitioned queries.
Virtual Scan
	A Virtual Scan represents a FETCH against a datasource that would spawn multiple queries partitioned by the partition column.
Data Source Path	The path of each of the datasource that is being used in each virtual scan.
Data Source Type	The type of each of the datasource that is being used in each virtual scan.
Estimated Row Data Volume	The estimated row data volume in bytes.
Estimated Number of Rows	The estimated number of rows that is returned in each virtual scan.
Estimated Total Data Volume	The estimated total data volume for each virtual scan.
Partition Count	Partition Count represents the number of ranges of the partition column that is dynamically computed. It indicates the number of partitioned queries that will be issued as part of each virtual scan.
Partition Column Name	This is the column chosen as the most suitable candidate for issuing partitioned queries, most likely candidates are numeric columns.
Partition Rank	Partition rank is a weight assigned to candidate partition columns based on their data type, the uniqueness of their values and the type of statistics (detailed or boundary) available for the distribution of their values. One of the columns with the highest weight is designated as the partition column.

Note: On the top level SELECT node of the query execution plan, when there is a note “No Parallelization”, it indicates that the query did not match the conditions to be processed in parallel. Some of the reasons for such a scenario include Concurrent Request Limit not set, data sources characteristics not suitable for parallel processing, Case-sensitivity or Trailing space settings do not allow for parallel processing, Semi-join optimization takes precedence over parallel processing, etc. In these cases tune the appropriate settings to force parallel mode.

If you find that your query does not run in parallel mode though the query plan shows a Parallel Fetch then there could be a runtime failure that causes the Fallback to classic engine. The fallback reason will be logged in the DV log under Server > SQL Engine > Parallel Processing > Log Level (when it is set to HIGH). There could be various reasons why a runtime failure occurs: for example, the node got disconnected from the cluster, configured memory was not sufficient for query to finish, runtime code generation caused a failure, etc.