Optimize execution plan generation
Updated at:
This topic explains why generating a physical execution plan can be time-consuming and provides solutions to optimize the process.
Symptoms
When a physical execution plan for a job is being generated, the status in SubStatusHistory in Logview is 1235 SQLTask is splitting data sources or 1240 SQLTask is generating execution plan.
Causes and solutions
The following table describes the possible causes of this issue and their corresponding solutions.
| Cause | Description | Solution |
| Excessive number of partitions | When MaxCompute compiles a job, it processes the metadata for each partition read. It determines how to split the data and how much data to assign to each compute unit. This information is then written to the execution plan. A large number of partitions creates significant overhead, increasing compilation time. | Optimize your SQL query to reduce the number of partitions read. For example, use partition pruning to filter out unnecessary partitions, or split a large job into multiple smaller jobs. |
| Excessive number of small files | During job compilation, MaxCompute determines how to split data for each compute unit based on file sizes within a partition. A large number of small files increases the overhead of this splitting process, leading to longer compilation times. Small files are typically generated for two main reasons:
|
|
Note This performance impact is significant only with tens of thousands, or even hundreds of thousands, of partitions or small files. Dozens or hundreds of them typically do not cause noticeable delays.
Is this page helpful?