This topic presents TPC-H benchmark results for the parallel query feature on PolarDB for MySQL 8.0.1 and 8.0.2 Cluster Edition. Use these results to evaluate OLAP (Online Analytical Processing) performance gains before enabling parallel query in your environment.
How parallel query works
Parallel query reduces query response time by distributing data shards across multiple threads at the storage layer. The feature activates automatically when the queried data volume exceeds a threshold. For an overview, see Overview.
PolarDB for MySQL 8.0.1 distributes data shards to worker threads, which perform parallel computing and return results to the leader thread. The leader thread merges the results and returns the final output.
PolarDB for MySQL 8.0.2 introduces multi-phase parallel computing and cost-based optimization, overcoming two limitations of 8.0.1: the single leader thread performance bottleneck and imbalanced worker loads. After the first phase of parallel computing, data shards are redistributed to a parallel worker group for the next phase before the leader thread performs the final merge. This improves linear acceleration capabilities and enables more flexible parallel execution plans.
The following diagram shows parallel processing on a cluster with 8 cores and 32 GB memory.

Test environment
| Item | Details |
|---|---|
| Cluster specification | 8 cores, 32 GB memory |
| Benchmark | TPC-H (22 queries, Q1–Q22) |
| Test type | OLAP |
Parallel query parameters
The following tables list the parameter values used in the OLAP tests. To configure these parameters, see Configure cluster and node parameters. For the full test methods, see Performance test for parallel queries.
PolarDB for MySQL 8.0.1
| Parameter | Default value | Test value (option 1) |
|---|---|---|
loose_parallel_degree_policy | REPLICA_AUTO | TYPICAL |
loose_max_parallel_degree | 0 | 16 |
PolarDB for MySQL 8.0.2
| Parameter | Default value | Test value (option 1) |
|---|---|---|
loose_parallel_degree_policy | REPLICA_AUTO | TYPICAL |
loose_parallel_query_switch | '' | 'force_run_using_planning_dop=on' |
loose_optimizer_switch | '' | 'hash_join_cost_based=off' |
loose_max_parallel_degree | 0 | 16 |
Whenloose_parallel_degree_policyis set toTYPICAL, PolarDB ignores database resource usage (such as CPU utilization) and sets the degree of parallelism (DOP) to the value ofloose_max_parallel_degree.
Verify that parallel query is active
After setting the parameters above, confirm that a query actually uses parallel execution before drawing conclusions from timing results. Run EXPLAIN on your target query and check the Extra column for the Using parallel query annotation:
EXPLAIN SELECT ...;If parallel query is active, the output includes entries similar to:
| ... | Using where; Using parallel query (4 columns, 1 filters, 1 exprs; 0 extra) |If the annotation is absent, the query is not using parallel execution. Common causes include a data volume below the activation threshold or a query pattern not yet supported by the parallel execution engine.
Test results
Version comparison
The following table summarizes total execution time across all 22 TPC-H queries, providing a high-level view of parallel query gains and the performance improvement from 8.0.1 to 8.0.2.
| Version | Default total (s) | Parallel total (s) | Overall acceleration |
|---|---|---|---|
| PolarDB 8.0.1 | 7,735.67 | 1,940.68 | ~4.0x |
| PolarDB 8.0.2 | 2,931.02 | 870.03 | ~3.4x |
The 8.0.2 default configuration already incorporates architectural improvements from 8.0.1, which is why the 8.0.2 default baseline is significantly faster than 8.0.1. Parallel query on 8.0.2 delivers a similar acceleration ratio over its own baseline, with absolute query times substantially faster across the board.
PolarDB for MySQL 8.0.1
| Query | Default (s) | Parallel (s) | Acceleration ratio |
|---|---|---|---|
| Q1 | 2,495.05 | 86.63 | 28.8x |
| Q2 | 13.18 | 1.46 | 9.0x |
| Q3 | 345.56 | 28.67 | 12.1x |
| Q4 | 63.78 | 6.26 | 10.2x |
| Q5 | 251.48 | 258.55 | 1.0x |
| Q6 | 241.70 | 16.40 | 14.7x |
| Q7 | 174.91 | 171.85 | 1.0x |
| Q8 | 560.82 | 572.63 | 1.0x |
| Q9 | 450.68 | 42.17 | 10.7x |
| Q10 | 895.75 | 270.29 | 3.3x |
| Q11 | 30.03 | 11.60 | 2.6x |
| Q12 | 266.14 | 17.65 | 15.1x |
| Q13 | 780.74 | 127.10 | 6.1x |
| Q14 | 72.04 | 7.57 | 9.5x |
| Q15 | 261.77 | 56.55 | 4.6x |
| Q16 | 40.69 | 24.29 | 1.7x |
| Q17 | 57.75 | 13.04 | 4.4x |
| Q18 | 257.66 | 136.79 | 1.9x |
| Q19 | 19.17 | 1.52 | 12.6x |
| Q20 | 143.97 | 49.72 | 2.9x |
| Q21 | 293.99 | 37.79 | 7.8x |
| Q22 | 18.81 | 2.15 | 8.7x |

Q5, Q7, and Q8 show minimal or no improvement under the 8.0.1 parallel configuration. These queries involve patterns (such as certain cross-table aggregations and join distributions) that do not benefit from the parallelism model in 8.0.1. PolarDB for MySQL 8.0.2 addresses these cases through multi-phase parallel computing.
PolarDB for MySQL 8.0.2
| Query | Default (s) | Parallel (s) | Acceleration ratio |
|---|---|---|---|
| Q1 | 573.34 | 89.65 | 6.4x |
| Q2 | 3.62 | 0.66 | 5.5x |
| Q3 | 96.89 | 28.52 | 3.4x |
| Q4 | 18.66 | 6.41 | 2.9x |
| Q5 | 150.93 | 28.93 | 5.2x |
| Q6 | 68.13 | 17.13 | 4.0x |
| Q7 | 114.56 | 17.39 | 6.6x |
| Q8 | 333.36 | 54.32 | 6.1x |
| Q9 | 136.26 | 42.15 | 3.2x |
| Q10 | 325.19 | 128.55 | 2.5x |
| Q11 | 11.49 | 4.53 | 2.5x |
| Q12 | 121.68 | 17.54 | 6.9x |
| Q13 | 281.10 | 126.20 | 2.2x |
| Q14 | 23.34 | 7.59 | 3.1x |
| Q15 | 77.22 | 33.02 | 2.3x |
| Q16 | 12.15 | 8.96 | 1.4x |
| Q17 | 4.51 | 1.13 | 4.0x |
| Q18 | 325.05 | 133.07 | 2.4x |
| Q19 | 5.37 | 1.50 | 3.6x |
| Q20 | 70.31 | 90.75 | 0.8x |
| Q21 | 171.81 | 29.87 | 5.8x |
| Q22 | 6.05 | 2.16 | 2.8x |

Q20 shows a slight regression under the 8.0.2 parallel configuration in this test. Query performance varies by data distribution and join patterns. Run tests with your own workload to validate results for your specific use case.
What's next
Configure cluster and node parameters — set the parallel query parameters for your cluster
Performance test for parallel queries — run TPC-H tests on your own cluster
Overview — learn more about the parallel query feature