Parallel query
When PostgreSQL scans a partitioned table, it uses an Append node to combine rows from each partition sequentially — one partition at a time. On large partitioned tables, this sequential scan creates a throughput bottleneck. PolarDB for PostgreSQL (Compatible with Oracle) addresses this with parallel append, which distributes workers across partitions, within partitions, or both simultaneously. Parallel append is enabled by default.
How parallel append works
In a non-parallel plan, an Append node processes each partition one at a time, so all workers assigned to the query cooperate on one partition before moving to the next. Parallel append replaces or augments this sequential scan by distributing workers differently.
PolarDB for PostgreSQL (Compatible with Oracle) supports three parallel append strategies:
| Strategy | Workers | Partitions |
|---|---|---|
| Inter-partition | One worker per partition | All partitions scanned concurrently |
| Intra-partition | Multiple workers per partition | Partitions processed sequentially |
| Hybrid | Multiple workers per partition | All partitions scanned concurrently |
Each strategy has its own cost model. The optimizer evaluates all three and selects the most efficient one for the query.
Parallel append strategies
Inter-partition parallel append
Each worker is assigned to one partition, so all partitions are scanned at the same time. The query plan uses the Parallel Append operator with Seq Scan on each partition.
EXPLAIN (COSTS OFF) SELECT * FROM prt1;
QUERY PLAN
-----------------------------------------------
Gather
Workers Planned: 6
-> Parallel Append
-> Seq Scan on prt1_p5
-> Seq Scan on prt1_default
-> Seq Scan on prt1_p4
-> Seq Scan on prt1_p1
-> Seq Scan on prt1_p2
-> Seq Scan on prt1_p3
(9 rows)
In this example, prt1 has six partitions (prt1_p1 through prt1_p5 and prt1_default). The optimizer plans six workers — one per partition. Each worker completes a full sequential scan of its assigned partition before the Gather node merges the results.
Intra-partition parallel append
Workers parallelize the scan within each partition, but partitions are processed sequentially. The query plan uses the Append operator with Parallel Seq Scan on each partition.
EXPLAIN (COSTS OFF) SELECT * FROM prt1;
QUERY PLAN
-----------------------------------------------
Gather
Workers Planned: 6
-> Append
-> Parallel Seq Scan on prt1_p5
-> Parallel Seq Scan on prt1_default
-> Parallel Seq Scan on prt1_p4
-> Parallel Seq Scan on prt1_p1
-> Parallel Seq Scan on prt1_p2
-> Parallel Seq Scan on prt1_p3
(9 rows)
In this example, six workers cooperate to scan each partition in turn. Although partitions are scanned sequentially, the scan of each partition is parallelized across all six workers.
Hybrid parallel append
Workers parallelize the scan both within partitions and across partitions. This strategy combines Parallel Append with Parallel Seq Scan, achieving the highest degree of parallelism. The optimizer typically allocates more workers than the number of partitions to keep all workers busy.
EXPLAIN (COSTS OFF) SELECT * FROM prt1;
QUERY PLAN
-----------------------------------------------
Gather
Workers Planned: 8
-> Parallel Append
-> Parallel Seq Scan on prt1_p5
-> Parallel Seq Scan on prt1_default
-> Parallel Seq Scan on prt1_p4
-> Parallel Seq Scan on prt1_p1
-> Parallel Seq Scan on prt1_p2
-> Parallel Seq Scan on prt1_p3
(9 rows)
In this example, eight workers handle six partitions. The extra workers beyond the partition count are distributed inside partitions to maximize concurrency.
Identify the active strategy
Use EXPLAIN (COSTS OFF) to see which strategy the optimizer chose. Look for these operator combinations in the query plan:
| Operator combination | Strategy |
|---|---|
Parallel Append + Seq Scan |
Inter-partition |
Append + Parallel Seq Scan |
Intra-partition |
Parallel Append + Parallel Seq Scan |
Hybrid |