[
https://issues.apache.org/jira/browse/IMPALA-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736661#comment-17736661
]
ASF subversion and git services commented on IMPALA-12192:
----------------------------------------------------------
Commit 7a94adbc3076881f6e7043a429a7294a04bd7519 in impala's branch
refs/heads/master from Riza Suminto
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=7a94adbc3 ]
IMPALA-12192: Fix scaling bug in scan fragment
IMPALA-12091 has a bug where scan fragment parallelism will always be
limited solely by the ScanNode cost. If ScanNode is colocated with other
query node operators that have higher processing costs, Planner will not
scale it up beyond what is allowed by the ScanNode cost.
This patch fixes the problem in two aspects. The first is to allow a
scan fragment to scale up higher as long as it is within the total
fragment cost and the number of effective scan ranges. The second is to
add missing Math.max() in CostingSegment.java which causes lower
fragment parallelism even when the total fragment cost is high.
IMPALA-10287 optimization is re-enabled to reduce regression in TPC-DS
Q78. Ideally, the broadcast vs partitioned costing formula during
distributed planning should not rely on numInstance. But enabling this
optimization ensures consistent query plan shape when comparing against
MT_DOP plan. This optimization can still be disabled by specifying
USE_DOP_FOR_COSTING=false.
This patch also does some cleanup including:
- Fix "max-parallelism" value in explain string.
- Make a constant in ScanNode.rowMaterializationCost() into a backend
flag named scan_range_cost_factor for experimental purposes.
- Replace all references to ProcessingCost.isComputeCost() to
queryOptions.isCompute_processing_cost() directly.
- Add Precondition in PlanFragment.getNumInstances() to verify that the
fragment's num instance is not modified anymore after the costing
algorithm finish.
Testing:
- Manually run TPCDS Q84 over tpcds10_parquet and confirm that the
leftmost scan fragment parallelism is raised from 12 (before the
patch) to 18 (after the patch).
- Add test in PlannerTest.testProcessingCost that reproduces the issue.
- Update compute stats test in test_executor_groups.py to maintain test
assertion.
- Pass core tests.
Change-Id: I7010f6c3bc48ae3f74e8db98a83f645b6c157226
Reviewed-on: http://gerrit.cloudera.org:8080/20024
Reviewed-by: Impala Public Jenkins <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
> Scan fragment parallelism is limited by its ScanNode cost.
> ----------------------------------------------------------
>
> Key: IMPALA-12192
> URL: https://issues.apache.org/jira/browse/IMPALA-12192
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
> Reporter: Riza Suminto
> Assignee: Riza Suminto
> Priority: Major
> Fix For: Impala 4.3.0
>
>
> IMPALA-12091 implement processing cost for ScanNode. Scan fragment
> parallelism is capped by this ScanNode cost, originally intended to prevent
> scanner over-parallelization (small files problem).
> However, there is a bug in the implementation where scan fragment parallelism
> will always be limited solely by the ScanNode cost. If ScanNode is colocated
> with other query node operator that have higher processing cost, Planner will
> not scale it up beyond what is allowed by the ScanNode cost. Scan fragment
> should be allowed to scale up, as long as it is within total processing cost
> of the fragment and number of effective scan ranges.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
