[Ideas] Add ORCA intra-segment parallel scan support for partitioned AO tables

[Alena0704]

Description

Preliminary measurements: These are noisy, uncontrolled measurements collected on my laptop with background applications running, not a clean benchmark. I plan to repeat the measurements on a virtual machine with a cold cache. Treat the timings and speedup ratios below as provisional.

For SELECT count(*) FROM ao13 over a row-oriented append-optimized table with 13 daily partitions and 6 million rows, ORCA uses a serial Dynamic Seq Scan within each segment even when enable_parallel=on and max_parallel_workers_per_gather=4. The PostgreSQL planner produces Parallel Append over Parallel Seq Scan. Disabling optimizer_enable_dynamictablescan causes PostgreSQL fallback for this query.

The parallel PostgreSQL plan reduces median execution time from 751.380 to 659.712 ms on unmodified upstream main (12.2% less time; 1.14× speedup) and from 713.039 to 649.303 ms on unmodified upstream REL_2_STABLE (8.9% less time; 1.10× speedup), with gp_resqueue_priority=off. Parallel Append lets multiple execution participants within each segment share the partition-scan work, rather than having one participant scan all partitions sequentially. The measured parallel plans have 12 sending participants across three physical segments, versus three for ORCA. This distributes scan and partial-aggregation work across more CPU cores; scheduling overhead, work granularity and host load limit the resulting speedup. The fallback uses the same PostgreSQL parallel execution mechanism.

The limitation reproduces on both unmodified upstream branches. This appears to be a missing capability in ORCA's intra-segment parallel scan support, rather than a cost-model choice between serial and parallel dynamic scan alternatives. Parallel execution improves this query's elapsed time in these measurements, but does not close the performance gap to GP6 on the unmodified builds; the cross-system comparison is included below.

Every timing and plan in this report was collected with gp_resqueue_priority=off on the coordinator and all three primary segments. Each mode has one warm-up followed by five measured runs. Tables report execution times in milliseconds; full plans are from measured round 5.

Environment and procedure

• Test date: October 14, 2026; macOS arm64 host, 14 logical CPUs, 24 GiB RAM.
• Each cluster has three primary segments on the same host and database codex_ao13_verify_20261014.
• Same table definition, data generation, distribution on id, 13 daily partitions and 6 million rows across builds.
• gp_resource_manager=queue, gp_resqueue_priority=off, statement_mem=128000 kB and 16 MiB shared buffers.
• Cloudberry: max_parallel_workers_per_gather=4, optimizer_disable_dynamic_table_scan=off in every mode.
• One persistent psql session per build; one warm-up EXPLAIN per mode, then five measured rounds, with mode order shuffled using seed 1306. Round 0 is excluded from statistics.
• The build benchmarks ran sequentially. No other benchmarks or builds were launched by this investigation during measurement. Other host applications remained running; process-load samples were recorded every two seconds. This is not an isolated-host benchmark.
• No OS cache flushing was performed. An explicit count was checked once per mode during warm-up: all benchmark count checks returned 6000000.

gp_resqueue_priority is a startup setting. It was disabled through postgres startup options on every node, with cluster restart where necessary; it was not changed using a session SET. The setting was verified on every node (direct utility connections for the clean Cloudberry clusters; coordinator SHOW plus distributed pg_settings queries for GP6 and the PR build), and through SHOW in each benchmark session. The test clusters remain running with this startup override.

Cluster startup option and setting verification

# Add this option to the existing postgres startup arguments on every node:
-c gp_resqueue_priority=off

SHOW gp_resqueue_priority;  -- must report off

The exact restart and sequential measurement procedure is in run_priority_off_comparison.py. Preserve the appropriate dispatch/execute role arguments when restarting nodes.

Reproduction SQL

Create and populate this table in each test database where ao13 does not already exist:

Create, populate and analyze ao13

CREATE TABLE ao13 (
    id bigint,
    d date,
    col1 int,
    col2 int,
    pad text
)
WITH (appendonly=true, orientation=row)
DISTRIBUTED BY (id)
PARTITION BY RANGE (d) (
    START ('2020-01-01'::date)
    END ('2020-01-14'::date)
    EVERY ('1 day'::interval)
);

INSERT INTO ao13
SELECT
    g,
    '2020-01-01'::date + (g % 13),
    g % 97,
    g % 89,
    repeat('x', 50)
FROM generate_series(1, 6000000) g;

ANALYZE ao13;

The SQL for each optimizer mode accompanies its plan below. In Cloudberry, disabling optimizer_enable_dynamictablescan prevents a specific ORCA transformation; fallback is verified for this query, not guaranteed for arbitrary queries. The distinct optimizer_disable_dynamic_table_scan remains off. Setting it to on enables ORCA's existing dynamic-scan-to-Append translation, which does not itself provide the parallel alternative described here.

Transaction-scoped fallback reproduction

BEGIN;
SET LOCAL optimizer = on;
SET LOCAL optimizer_enable_dynamictablescan = off;
SET LOCAL optimizer_disable_dynamic_table_scan = off;
SET LOCAL enable_parallel = on;
SET LOCAL max_parallel_workers_per_gather = 4;
EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;
COMMIT;

Cloudberry unmodified upstream main

Source commit 3a586f12c2c2011989734be383ddea69aac24abb, verified against upstream main on October 14, 2026. All 19,632 tracked files and symbolic links matched the commit; no local feature patches or PR #2094 code were applied. Cloudberry 3.0.0-devel / PostgreSQL 16.9, Apple Clang 21, --enable-debug --enable-cassert --enable-orca, CFLAGS='-O0 -g', CXXFLAGS='-O0 -g'.

ORCA, parallel on

Reproduction SQL

SET optimizer = on;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 3:1  (slice1; segments: 3) (actual rows=3 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Dynamic Seq Scan on ao13 (actual rows=2001127 loops=1)
                     Number of partitions to scan: 13 (out of 13)
                     Partitions scanned:  Avg 13.0 x 3 workers.  Max 13 parts (seg0).
 Planning Time: 10.136 ms
   (slice0)    Executor memory: 114K bytes.
   (slice1)    Executor memory: 293K bytes avg x 3x(0) workers, 293K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: GPORCA
 Execution Time: 751.380 ms

PostgreSQL, parallel off

Reproduction SQL

SET optimizer = off;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = off;
SET max_parallel_workers_per_gather = 4;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 3:1  (slice1; segments: 3) (actual rows=3 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Append (actual rows=2001127 loops=1)
                     ->  Seq Scan on ao13_1_prt_1 ao13_1 (actual rows=154105 loops=1)
                     ->  Seq Scan on ao13_1_prt_2 ao13_2 (actual rows=154176 loops=1)
                     ->  Seq Scan on ao13_1_prt_3 ao13_3 (actual rows=154082 loops=1)
                     ->  Seq Scan on ao13_1_prt_4 ao13_4 (actual rows=154188 loops=1)
                     ->  Seq Scan on ao13_1_prt_5 ao13_5 (actual rows=154322 loops=1)
                     ->  Seq Scan on ao13_1_prt_6 ao13_6 (actual rows=154181 loops=1)
                     ->  Seq Scan on ao13_1_prt_7 ao13_7 (actual rows=153987 loops=1)
                     ->  Seq Scan on ao13_1_prt_8 ao13_8 (actual rows=154014 loops=1)
                     ->  Seq Scan on ao13_1_prt_9 ao13_9 (actual rows=153906 loops=1)
                     ->  Seq Scan on ao13_1_prt_10 ao13_10 (actual rows=154053 loops=1)
                     ->  Seq Scan on ao13_1_prt_11 ao13_11 (actual rows=154613 loops=1)
                     ->  Seq Scan on ao13_1_prt_12 ao13_12 (actual rows=154118 loops=1)
                     ->  Seq Scan on ao13_1_prt_13 ao13_13 (actual rows=154235 loops=1)
 Planning Time: 1.897 ms
   (slice0)    Executor memory: 148K bytes.
   (slice1)    Executor memory: 1962K bytes avg x 3x(0) workers, 1962K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 759.444 ms

PostgreSQL, parallel on

Reproduction SQL

SET optimizer = off;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 12:1  (slice1; segments: 12) (actual rows=12 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Parallel Append (actual rows=461424 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_2 ao13_2 (actual rows=154176 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_3 ao13_3 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_4 ao13_4 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_5 ao13_5 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_6 ao13_6 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_7 ao13_7 (actual rows=153987 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_1 ao13_1 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_8 ao13_8 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_9 ao13_9 (actual rows=153906 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_10 ao13_10 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_11 ao13_11 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_12 ao13_12 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_13 ao13_13 (never executed)
 Planning Time: 2.045 ms
   (slice0)    Executor memory: 148K bytes.
   (slice1)    Executor memory: 816K bytes avg x 12x(0) workers, 991K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 628.481 ms

ORCA requested, dynamic scan disabled (fallback)

Reproduction SQL

SET optimizer = on;
SET optimizer_enable_dynamictablescan = off;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 12:1  (slice1; segments: 12) (actual rows=12 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Parallel Append (actual rows=615803 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_2 ao13_2 (actual rows=154176 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_3 ao13_3 (actual rows=154082 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_4 ao13_4 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_5 ao13_5 (actual rows=154322 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_6 ao13_6 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_7 ao13_7 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_1 ao13_1 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_8 ao13_8 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_9 ao13_9 (actual rows=153906 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_10 ao13_10 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_11 ao13_11 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_12 ao13_12 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_13 ao13_13 (never executed)
 Planning Time: 6.685 ms
   (slice0)    Executor memory: 148K bytes.
   (slice1)    Executor memory: 816K bytes avg x 12x(0) workers, 991K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 645.408 ms

Cloudberry unmodified upstream REL_2_STABLE

Official apache/cloudberry REL_2_STABLE commit 2257219513c0e970665f900bdd6ff6e8b49a4d07, verified against upstream on October 14, 2026. All 18,935 tracked files and symbolic links matched the commit; no local feature patches were applied. Cloudberry 2.2.0-incubating / PostgreSQL 14.10, Apple Clang 21, --enable-debug --enable-cassert --enable-orca, CFLAGS='-O0 -g', CXXFLAGS='-O0 -g'.

ORCA, parallel on

Reproduction SQL

SET optimizer = on;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 3:1  (slice1; segments: 3) (actual rows=3 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Dynamic Seq Scan on ao13 (actual rows=2001127 loops=1)
                     Number of partitions to scan: 13 (out of 13)
                     Partitions scanned:  Avg 13.0 x 3 workers.  Max 13 parts (seg0).
 Planning Time: 10.348 ms
   (slice0)    Executor memory: 114K bytes.
   (slice1)    Executor memory: 309K bytes avg x 3x(0) workers, 309K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: GPORCA
 Execution Time: 713.039 ms

PostgreSQL, parallel off

Reproduction SQL

SET optimizer = off;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = off;
SET max_parallel_workers_per_gather = 4;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 3:1  (slice1; segments: 3) (actual rows=3 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Append (actual rows=2001127 loops=1)
                     ->  Seq Scan on ao13_1_prt_1 ao13_1 (actual rows=154105 loops=1)
                     ->  Seq Scan on ao13_1_prt_2 ao13_2 (actual rows=154176 loops=1)
                     ->  Seq Scan on ao13_1_prt_3 ao13_3 (actual rows=154082 loops=1)
                     ->  Seq Scan on ao13_1_prt_4 ao13_4 (actual rows=154188 loops=1)
                     ->  Seq Scan on ao13_1_prt_5 ao13_5 (actual rows=154322 loops=1)
                     ->  Seq Scan on ao13_1_prt_6 ao13_6 (actual rows=154181 loops=1)
                     ->  Seq Scan on ao13_1_prt_7 ao13_7 (actual rows=153987 loops=1)
                     ->  Seq Scan on ao13_1_prt_8 ao13_8 (actual rows=154014 loops=1)
                     ->  Seq Scan on ao13_1_prt_9 ao13_9 (actual rows=153906 loops=1)
                     ->  Seq Scan on ao13_1_prt_10 ao13_10 (actual rows=154053 loops=1)
                     ->  Seq Scan on ao13_1_prt_11 ao13_11 (actual rows=154613 loops=1)
                     ->  Seq Scan on ao13_1_prt_12 ao13_12 (actual rows=154118 loops=1)
                     ->  Seq Scan on ao13_1_prt_13 ao13_13 (actual rows=154235 loops=1)
 Planning Time: 1.919 ms
   (slice0)    Executor memory: 159K bytes.
   (slice1)    Executor memory: 1977K bytes avg x 3x(0) workers, 1977K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 771.687 ms

PostgreSQL, parallel on

Reproduction SQL

SET optimizer = off;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 12:1  (slice1; segments: 12) (actual rows=12 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Parallel Append (actual rows=461612 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_2 ao13_2 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_3 ao13_3 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_4 ao13_4 (actual rows=154188 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_5 ao13_5 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_6 ao13_6 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_7 ao13_7 (actual rows=153987 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_1 ao13_1 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_8 ao13_8 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_9 ao13_9 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_10 ao13_10 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_11 ao13_11 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_12 ao13_12 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_13 ao13_13 (never executed)
 Planning Time: 1.894 ms
   (slice0)    Executor memory: 159K bytes.
   (slice1)    Executor memory: 831K bytes avg x 12x(0) workers, 1006K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 701.060 ms

ORCA requested, dynamic scan disabled (fallback)

Reproduction SQL

SET optimizer = on;
SET optimizer_enable_dynamictablescan = off;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 12:1  (slice1; segments: 12) (actual rows=12 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Parallel Append (actual rows=615803 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_2 ao13_2 (actual rows=154176 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_3 ao13_3 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_4 ao13_4 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_5 ao13_5 (actual rows=154322 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_6 ao13_6 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_7 ao13_7 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_1 ao13_1 (actual rows=0 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_8 ao13_8 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_9 ao13_9 (actual rows=153906 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_10 ao13_10 (actual rows=0 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_11 ao13_11 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_12 ao13_12 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_13 ao13_13 (never executed)
 Planning Time: 7.737 ms
   (slice0)    Executor memory: 159K bytes.
   (slice1)    Executor memory: 831K bytes avg x 12x(0) workers, 1006K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 681.414 ms

Cloudberry 3.0.0-devel + PR #2094

PR #2094 was an attempt to address the AO scan performance problem observed in this scenario, so a build including this PR was also benchmarked. It targets tuple-processing overhead through lazy attribute extraction; it does not add parallel Dynamic Seq Scan support.

Main-based PR #2094 test build, source commit afbf74172d91cb411752963c9e99dec1e0bc3565. Cloudberry 3.0.0-devel / PostgreSQL 16.9, Apple Clang 21, assertion-enabled debug build compiled October 10, 2026. Block size: 8 KiB. Coordinator port 20940, segment ports 20941–20943.

This is not unmodified upstream main. PR #2094 adds lazy AO MemTuple attribute extraction, which allows count(*) to avoid eager tuple deformation. The block size also differs from the clean builds; the timing difference is not an isolated measurement of the PR's benefit.

ORCA, parallel on

Reproduction SQL

SET optimizer = on;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 3:1  (slice1; segments: 3) (actual rows=3 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Dynamic Seq Scan on ao13 (actual rows=2001127 loops=1)
                     Number of partitions to scan: 13 (out of 13)
                     Partitions scanned:  Avg 13.0 x 3 workers.  Max 13 parts (seg0).
 Planning Time: 9.414 ms
   (slice0)    Executor memory: 114K bytes.
   (slice1)    Executor memory: 295K bytes avg x 3x(0) workers, 295K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: GPORCA
 Execution Time: 491.383 ms

PostgreSQL, parallel off

Reproduction SQL

SET optimizer = off;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = off;
SET max_parallel_workers_per_gather = 4;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 3:1  (slice1; segments: 3) (actual rows=3 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Append (actual rows=2001127 loops=1)
                     ->  Seq Scan on ao13_1_prt_1 ao13_1 (actual rows=154105 loops=1)
                     ->  Seq Scan on ao13_1_prt_2 ao13_2 (actual rows=154176 loops=1)
                     ->  Seq Scan on ao13_1_prt_3 ao13_3 (actual rows=154082 loops=1)
                     ->  Seq Scan on ao13_1_prt_4 ao13_4 (actual rows=154188 loops=1)
                     ->  Seq Scan on ao13_1_prt_5 ao13_5 (actual rows=154322 loops=1)
                     ->  Seq Scan on ao13_1_prt_6 ao13_6 (actual rows=154181 loops=1)
                     ->  Seq Scan on ao13_1_prt_7 ao13_7 (actual rows=153987 loops=1)
                     ->  Seq Scan on ao13_1_prt_8 ao13_8 (actual rows=154014 loops=1)
                     ->  Seq Scan on ao13_1_prt_9 ao13_9 (actual rows=153906 loops=1)
                     ->  Seq Scan on ao13_1_prt_10 ao13_10 (actual rows=154053 loops=1)
                     ->  Seq Scan on ao13_1_prt_11 ao13_11 (actual rows=154613 loops=1)
                     ->  Seq Scan on ao13_1_prt_12 ao13_12 (actual rows=154118 loops=1)
                     ->  Seq Scan on ao13_1_prt_13 ao13_13 (actual rows=154235 loops=1)
 Planning Time: 2.039 ms
   (slice0)    Executor memory: 149K bytes.
   (slice1)    Executor memory: 1964K bytes avg x 3x(0) workers, 1964K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 528.390 ms

PostgreSQL, parallel on

Reproduction SQL

SET optimizer = off;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 12:1  (slice1; segments: 12) (actual rows=12 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Parallel Append (actual rows=461815 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_2 ao13_2 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_3 ao13_3 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_4 ao13_4 (actual rows=154188 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_5 ao13_5 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_6 ao13_6 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_7 ao13_7 (actual rows=153987 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_1 ao13_1 (actual rows=154105 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_8 ao13_8 (actual rows=154014 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_9 ao13_9 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_10 ao13_10 (actual rows=154053 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_11 ao13_11 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_12 ao13_12 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_13 ao13_13 (never executed)
 Planning Time: 1.949 ms
   (slice0)    Executor memory: 149K bytes.
   (slice1)    Executor memory: 818K bytes avg x 12x(0) workers, 993K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 494.462 ms

ORCA requested, dynamic scan disabled (fallback)

Reproduction SQL

SET optimizer = on;
SET optimizer_enable_dynamictablescan = off;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 12:1  (slice1; segments: 12) (actual rows=12 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Parallel Append (actual rows=462022 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_2 ao13_2 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_3 ao13_3 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_4 ao13_4 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_5 ao13_5 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_6 ao13_6 (actual rows=154181 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_7 ao13_7 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_1 ao13_1 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_8 ao13_8 (actual rows=154014 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_9 ao13_9 (actual rows=153906 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_10 ao13_10 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_11 ao13_11 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_12 ao13_12 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_13 ao13_13 (never executed)
 Planning Time: 6.398 ms
   (slice0)    Executor memory: 149K bytes.
   (slice1)    Executor memory: 818K bytes avg x 12x(0) workers, 993K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 444.927 ms

GP6-based OpenGPDB

Installed binary: PostgreSQL 9.4.26 (Greenplum Database 6.28.8-python+dev.233.g9f785ada8a build dev), compiled July 17, 2026 with Apple Clang 17, -O0 -g3, without assertions. This is a GP6-based OpenGPDB build. Block size: 32 KiB. Coordinator port 21640, segment ports 21641–21643.

The table setup and warm-up/five-run protocol match Cloudberry. Cloudberry-specific parallel GUCs are not used. Compiler, assertion and codebase differences prevent interpreting cross-build timings as an isolated GP6-versus-Cloudberry engine regression.

ORCA

Reproduction SQL

SET optimizer = on;
SET optimizer_enable_dynamictablescan = on;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 3:1  (slice1; segments: 3) (actual rows=3 loops=1)
         ->  Aggregate (actual rows=1 loops=1)
               ->  Sequence (actual rows=2001127 loops=1)
                     ->  Partition Selector for ao13 (dynamic scan id: 1) (never executed)
                           Partitions selected: 13 (out of 13)
                     ->  Dynamic Seq Scan on ao13 (dynamic scan id: 1) (actual rows=2001127 loops=1)
                           Partitions scanned:  Avg 13.0 (out of 13) x 3 workers.  Max 13 parts (seg0).
 Planning time: 3.338 ms
   (slice0)    Executor memory: 67K bytes.
   (slice1)    Executor memory: 522K bytes avg x 3 workers, 522K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Pivotal Optimizer (GPORCA)
 Execution time: 517.615 ms

PostgreSQL

Reproduction SQL

SET optimizer = off;
SET optimizer_enable_dynamictablescan = on;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 3:1  (slice1; segments: 3) (actual rows=3 loops=1)
         ->  Aggregate (actual rows=1 loops=1)
               ->  Append (actual rows=2001127 loops=1)
                     ->  Seq Scan on ao13_1_prt_1 (actual rows=154105 loops=1)
                     ->  Seq Scan on ao13_1_prt_2 (actual rows=154176 loops=1)
                     ->  Seq Scan on ao13_1_prt_3 (actual rows=154082 loops=1)
                     ->  Seq Scan on ao13_1_prt_4 (actual rows=154188 loops=1)
                     ->  Seq Scan on ao13_1_prt_5 (actual rows=154322 loops=1)
                     ->  Seq Scan on ao13_1_prt_6 (actual rows=154181 loops=1)
                     ->  Seq Scan on ao13_1_prt_7 (actual rows=153987 loops=1)
                     ->  Seq Scan on ao13_1_prt_8 (actual rows=154014 loops=1)
                     ->  Seq Scan on ao13_1_prt_9 (actual rows=153906 loops=1)
                     ->  Seq Scan on ao13_1_prt_10 (actual rows=154053 loops=1)
                     ->  Seq Scan on ao13_1_prt_11 (actual rows=154613 loops=1)
                     ->  Seq Scan on ao13_1_prt_12 (actual rows=154118 loops=1)
                     ->  Seq Scan on ao13_1_prt_13 (actual rows=154235 loops=1)
 Planning time: 0.493 ms
   (slice0)    Executor memory: 459K bytes.
   (slice1)    Executor memory: 2027K bytes avg x 3 workers, 2027K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution time: 479.035 ms

Experimental backport of PR #2094 to REL_2_STABLE

PR #2094 snapshot afbf74172d91cb411752963c9e99dec1e0bc3565 was ported to upstream REL_2_STABLE commit 2257219513c0e970665f900bdd6ff6e8b49a4d07 in a separate source tree and cluster. All 11 implementation-file diffs were applied. Two compatibility adaptations were required: insert ri_projectNewNeedsOldTuple using the PG14 struct layout, and remove the PG16-only pg_node_attr(abstract) annotation. PR expected-output changes were not imported.

The backend and required extensions were rebuilt cleanly with the same compiler and debug/assertion configuration as the clean REL_2_STABLE build, with 32 KiB blocks and 16 MiB shared buffers. Coordinator port 21740; three primary segments on 21741–21743. gp_resqueue_priority=off was verified on all nodes of both clusters.

This experimental backport has a reproduced correctness failure in ORCA UPDATE of an AO table with a stored generated column. It is not a validated release-ready backport. The failure and exact reproduction are documented below; the count(*) timings remain a read-only experiment.

Direct comparison on REL_2_STABLE

The clean baseline and patched cluster were benchmarked sequentially after compilation and targeted checks finished, each using the same table setup, one warm-up and five measured runs per mode. All eight explicit count checks returned 6000000. This dedicated comparison has its own clean-baseline measurements; use the two columns below together. The laptop/background-load qualification at the start of this issue also applies here.

Mode	Clean REL_2_STABLE median, ms	REL_2_STABLE + PR #2094 median, ms	Speedup	Execution-time reduction
ORCA, parallel on	737.715	502.429	1.47×	31.9%
PostgreSQL, parallel off	783.095	546.616	1.43×	30.2%
PostgreSQL, parallel on	612.403	420.974	1.45×	31.3%
ORCA requested, dynamic scan disabled (fallback)	645.757	423.416	1.53×	34.4%

Build / mode	Five measured runs, ms
Clean REL_2_STABLE: ORCA, parallel on	1297.874, 1055.004, 737.715, 718.399, 717.628
Clean REL_2_STABLE: PostgreSQL, parallel off	1300.733, 790.665, 757.807, 783.095, 735.744
Clean REL_2_STABLE: PostgreSQL, parallel on	1160.053, 659.687, 600.154, 584.615, 612.403
Clean REL_2_STABLE: ORCA requested, dynamic scan disabled (fallback)	1221.777, 513.941, 615.064, 645.757, 646.302
Experimental backport: ORCA, parallel on	499.034, 502.429, 490.401, 526.339, 511.780
Experimental backport: PostgreSQL, parallel off	554.047, 545.989, 546.616, 512.422, 553.171
Experimental backport: PostgreSQL, parallel on	425.496, 409.458, 420.974, 422.405, 412.598
Experimental backport: ORCA requested, dynamic scan disabled (fallback)	461.747, 455.063, 388.207, 423.416, 385.274

The ORCA plan remains Dynamic Seq Scan; PostgreSQL parallel and fallback retain Parallel Append. This is an AO tuple-processing improvement, not parallel Dynamic Seq Scan support. The baseline's first measured round was noticeably slower than subsequent rounds, so these provisional laptop timings should not be treated as a precise production speedup.

Experimental backport: query SQL and complete plans

ORCA, parallel on

Reproduction SQL

SET optimizer = on;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;
EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 3:1  (slice1; segments: 3) (actual rows=3 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Dynamic Seq Scan on ao13 (actual rows=2001127 loops=1)
                     Number of partitions to scan: 13 (out of 13)
                     Partitions scanned:  Avg 13.0 x 3 workers.  Max 13 parts (seg0).
 Planning Time: 9.067 ms
   (slice0)    Executor memory: 114K bytes.
   (slice1)    Executor memory: 311K bytes avg x 3x(0) workers, 311K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: GPORCA
 Execution Time: 511.780 ms

PostgreSQL, parallel off

Reproduction SQL

SET optimizer = off;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = off;
SET max_parallel_workers_per_gather = 4;
EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 3:1  (slice1; segments: 3) (actual rows=3 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Append (actual rows=2001127 loops=1)
                     ->  Seq Scan on ao13_1_prt_1 ao13_1 (actual rows=154105 loops=1)
                     ->  Seq Scan on ao13_1_prt_2 ao13_2 (actual rows=154176 loops=1)
                     ->  Seq Scan on ao13_1_prt_3 ao13_3 (actual rows=154082 loops=1)
                     ->  Seq Scan on ao13_1_prt_4 ao13_4 (actual rows=154188 loops=1)
                     ->  Seq Scan on ao13_1_prt_5 ao13_5 (actual rows=154322 loops=1)
                     ->  Seq Scan on ao13_1_prt_6 ao13_6 (actual rows=154181 loops=1)
                     ->  Seq Scan on ao13_1_prt_7 ao13_7 (actual rows=153987 loops=1)
                     ->  Seq Scan on ao13_1_prt_8 ao13_8 (actual rows=154014 loops=1)
                     ->  Seq Scan on ao13_1_prt_9 ao13_9 (actual rows=153906 loops=1)
                     ->  Seq Scan on ao13_1_prt_10 ao13_10 (actual rows=154053 loops=1)
                     ->  Seq Scan on ao13_1_prt_11 ao13_11 (actual rows=154613 loops=1)
                     ->  Seq Scan on ao13_1_prt_12 ao13_12 (actual rows=154118 loops=1)
                     ->  Seq Scan on ao13_1_prt_13 ao13_13 (actual rows=154235 loops=1)
 Planning Time: 1.879 ms
   (slice0)    Executor memory: 161K bytes.
   (slice1)    Executor memory: 1978K bytes avg x 3x(0) workers, 1978K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 553.171 ms

PostgreSQL, parallel on

Reproduction SQL

SET optimizer = off;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;
EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 12:1  (slice1; segments: 12) (actual rows=12 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Parallel Append (actual rows=462022 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_2 ao13_2 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_3 ao13_3 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_4 ao13_4 (actual rows=154188 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_5 ao13_5 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_6 ao13_6 (actual rows=154181 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_7 ao13_7 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_1 ao13_1 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_8 ao13_8 (actual rows=154014 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_9 ao13_9 (actual rows=153906 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_10 ao13_10 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_11 ao13_11 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_12 ao13_12 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_13 ao13_13 (never executed)
 Planning Time: 1.779 ms
   (slice0)    Executor memory: 161K bytes.
   (slice1)    Executor memory: 833K bytes avg x 12x(0) workers, 1008K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 412.598 ms

ORCA requested, dynamic scan disabled (fallback)

Reproduction SQL

SET optimizer = on;
SET optimizer_enable_dynamictablescan = off;
SET optimizer_disable_dynamic_table_scan = off;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;
EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao13;

Query execution plan — measured round 5

 Finalize Aggregate (actual rows=1 loops=1)
   ->  Gather Motion 12:1  (slice1; segments: 12) (actual rows=12 loops=1)
         ->  Partial Aggregate (actual rows=1 loops=1)
               ->  Parallel Append (actual rows=461625 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_2 ao13_2 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_3 ao13_3 (actual rows=154082 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_4 ao13_4 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_5 ao13_5 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_6 ao13_6 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_7 ao13_7 (actual rows=153987 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_1 ao13_1 (actual rows=154105 loops=1)
                     ->  Parallel Seq Scan on ao13_1_prt_8 ao13_8 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_9 ao13_9 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_10 ao13_10 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_11 ao13_11 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_12 ao13_12 (never executed)
                     ->  Parallel Seq Scan on ao13_1_prt_13 ao13_13 (never executed)
 Planning Time: 6.076 ms
   (slice0)    Executor memory: 161K bytes.
   (slice1)    Executor memory: 833K bytes avg x 12x(0) workers, 1008K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 385.274 ms

Correctness checks and known failure

With ORCA requested, 14 targeted assertions passed before the stored-generated-column UPDATE assertion failed. These checks cover wide rows, NULLs, arrays, large text, partial and late attribute reads, sort/materialization, index lookup, ordinary and distribution-key UPDATE, VACUUM compaction, column-layout changes and table rewrite. Some operations use PostgreSQL fallback, as recorded in the logs. The PostgreSQL-planner run completed all 16 assertions. These targeted checks are not a full regression suite.

A separate transaction-scoped reproduction confirmed the difference:

Build / requested optimizer	Actual UPDATE optimizer	Rows with incorrect generated value
Clean REL_2_STABLE / ORCA	PostgreSQL fallback	0 / 100
Clean REL_2_STABLE / PostgreSQL	PostgreSQL	0 / 100
Experimental backport / ORCA	GPORCA	100 / 100
Experimental backport / PostgreSQL	PostgreSQL	0 / 100

For example, the row (id=1, a=1, b=2) becomes (id=1, a=2, b=2) under the patched ORCA UPDATE, although b should become 4. The experiment establishes a regression in this backport; it does not establish the behavior of the same case on upstream main.

Stored generated column UPDATE reproduction

\set ON_ERROR_STOP on
SET optimizer = on;
BEGIN;
CREATE TABLE public.backport_generated_check (id int, a int, b int GENERATED ALWAYS AS (a*2) STORED) USING ao_row DISTRIBUTED BY(id);
INSERT INTO public.backport_generated_check (id,a) SELECT g,g FROM generate_series(1,100) g;
EXPLAIN (COSTS OFF) UPDATE public.backport_generated_check SET a=a+1;
UPDATE public.backport_generated_check SET a=a+1;
SELECT count(*) AS rows, count(*) FILTER (WHERE b IS DISTINCT FROM a*2) AS incorrect_generated_values FROM public.backport_generated_check;
SELECT * FROM public.backport_generated_check WHERE b IS DISTINCT FROM a*2 ORDER BY id LIMIT 5;
ROLLBACK;

Artifacts: backport patch, compatibility notes, build procedure, comparison runner, clean-baseline plans, clean-baseline measurements, backport plans, backport measurements, targeted SQL, ORCA test log, PostgreSQL test log, generated-column failure log.

Interpretation

All tested modes returned the expected count of 6,000,000 rows. ORCA used a serial Dynamic Seq Scan on both upstream branches, while the PostgreSQL planner produced Parallel Append.

Expected Cloudberry behavior

When parallel execution is enabled and safe, ORCA should be able to consider a parallel alternative for scanning partitioned AO tables and choose it when justified by cost.

The required outcome is parallel work distribution without changing query results or partition-pruning semantics. This could be implemented as a parallel-aware DynamicSeqScan or an appropriate Parallel Append plan; a particular plan-node representation is not required by this report.

Cloudberry code investigation

The following observations come from inspection of the local Cloudberry checkout:

1. src/backend/gporca/libgpopt/src/xforms/CXformGet2ParallelTableScan.cpp matches CLogicalGet. There is no corresponding parallel implementation transformation among the candidates in CLogicalDynamicGet::PxfsCandidates().
2. src/backend/executor/nodeDynamicSeqscan.c advances a local whichPart counter, opens a partition, and initializes its ordinary SeqScan through ExecInitSeqScanForPartition(). This does not distribute partitions between workers.
3. src/backend/executor/execParallel.c handles SeqScan and Append in its MPP DSM walkers, but has no DynamicSeqScanState handler.
4. CTranslatorDXLToPlStmt::ExtractParallelWorkersFromDXL() in src/backend/gpopt/translate/CTranslatorDXLToPlStmt.cpp treats EdxlopPhysicalDynamicTableScan as a non-parallel scan and returns degree 1.
5. src/backend/gpopt/config/CConfigParamMapping.cpp maps optimizer_enable_dynamictablescan = off to disabling ExfDynamicGet2DynamicTableScan, explaining the fallback observed for this query.

Potential implementation directions

For a parallel-aware DynamicSeqScan, a shared partition queue/counter could distribute whole partitions among workers within each segment. This would require coordinated partition-pruning results, DSM initialization and worker attachment, correct rescan behavior, and corresponding ORCA/DXL/plan-translation support. The ORCA implementation must also account for worker distribution, rewindability, and cost.

Whole-partition scheduling is a limited first step: it cannot parallelize a scan when pruning leaves only one partition. Sharing work within a partition would require additional support.

AO scan granularity also matters. In the inspected src/backend/access/appendonly/appendonlyam.c, parallel work allocation uses AO segment-file indexes. The number and sizes of readable AO files can limit effective parallelism even when a plan contains Parallel Seq Scan nodes.

An alternative is to extend ORCA's existing dynamic-scan-to-Append translation to generate a valid parallel plan and reuse the Parallel Append executor infrastructure.

Related discussions and PRs

• Discussion #1316 — Enhanced ORCA Parallel Planning to Align with PostgreSQL Planner: the broader proposal for closing the parallel-planning gap between ORCA and the PostgreSQL planner. PR orca: implement intra-segment parallel table scan support #1398 is identified as its first milestone.
• PR #1398 — implement intra-segment parallel table scan support, merged May 13, 2026: introduces CPhysicalParallelTableScan, CXformGet2ParallelTableScan, worker distribution, cost-model integration, and DXL support. Its description explicitly excludes dynamic scans from the supported scope.
• PR #1022 — ORCA: allow partition table use the append node, merged June 25, 2025: related to the existing Append translation and optimizer_disable_dynamic_table_scan setting. It is relevant to an alternative implementation direction, but does not itself resolve this parallel-planning gap in the inspected code.
• PR #647 — Refactor parallel scan node and framework, merged October 16, 2024: establishes the unified MPP DSM initialization approach for parallel scan nodes.
• PR #1512 — Fix assertion failure for dynamic table scan rewindability, merged December 29, 2025: relevant to preserving correct physical properties when extending DynamicTableScan.
• PR #1452 — [WIP] Orca parallel: closed without merging; included as related historical work, not an available fix.

Suggested validation for a fix

• Confirm count(*) = 6000000 with ORCA parallel execution enabled and disabled, and with the PostgreSQL planner.
• Verify that ORCA can produce a parallel partition scan when the alternative is safe and cost-effective.
• Cover static pruning, dynamic pruning, no matching partitions, one matching partition, and multiple partitions.
• Exercise rescans and parameter changes where supported, or verify that unsupported plan shapes are correctly rejected.
• Check partitions with different column layouts, empty partitions, uneven partition sizes, and different AO segment-file counts.
• Measure repeated runs under documented cache and build conditions; keep correctness and plan-shape checks separate from performance claims.

Final comparison — gp_resqueue_priority=off on every node

All rows use one warm-up and five measured runs; median excludes warm-up.

System	Mode	Actual scan	Run 5 execution, ms	Median execution, ms
Cloudberry unmodified upstream main	ORCA, parallel on	Dynamic Seq Scan	751.380	751.380
Cloudberry unmodified upstream main	PostgreSQL, parallel off	Append	759.444	759.444
Cloudberry unmodified upstream main	PostgreSQL, parallel on	Parallel Append	628.481	659.712
Cloudberry unmodified upstream main	ORCA requested, dynamic scan disabled (fallback)	Parallel Append	645.408	668.949
Cloudberry unmodified upstream REL_2_STABLE	ORCA, parallel on	Dynamic Seq Scan	713.039	713.039
Cloudberry unmodified upstream REL_2_STABLE	PostgreSQL, parallel off	Append	771.687	782.740
Cloudberry unmodified upstream REL_2_STABLE	PostgreSQL, parallel on	Parallel Append	701.060	649.303
Cloudberry unmodified upstream REL_2_STABLE	ORCA requested, dynamic scan disabled (fallback)	Parallel Append	681.414	614.259
Cloudberry 3.0.0-devel + PR #2094	ORCA, parallel on	Dynamic Seq Scan	491.383	476.438
Cloudberry 3.0.0-devel + PR #2094	PostgreSQL, parallel off	Append	528.390	517.919
Cloudberry 3.0.0-devel + PR #2094	PostgreSQL, parallel on	Parallel Append	494.462	378.813
Cloudberry 3.0.0-devel + PR #2094	ORCA requested, dynamic scan disabled (fallback)	Parallel Append	444.927	443.250
GP6-based OpenGPDB	ORCA	Dynamic Seq Scan	517.615	442.338
GP6-based OpenGPDB	PostgreSQL	Append	479.035	461.166
REL_2_STABLE + PR #2094 (experimental; known UPDATE failure)	ORCA, parallel on	Dynamic Seq Scan	511.780	502.429
REL_2_STABLE + PR #2094 (experimental; known UPDATE failure)	PostgreSQL, parallel off	Append	553.171	546.616
REL_2_STABLE + PR #2094 (experimental; known UPDATE failure)	PostgreSQL, parallel on	Parallel Append	412.598	420.974
REL_2_STABLE + PR #2094 (experimental; known UPDATE failure)	ORCA requested, dynamic scan disabled (fallback)	Parallel Append	385.274	423.416

The experimental backport has a dedicated paired baseline and known correctness failure documented above.

Execution time relative to GP6

The reference medians are 442.338 ms for GP6 ORCA and 461.166 ms for the GP6 PostgreSQL planner. The table shows Cloudberry execution time / GP6 execution time: a ratio above 1 means Cloudberry took longer; a ratio below 1 means it took less time.

ORCA is compared with GP6 ORCA. All PostgreSQL execution modes, including ORCA fallback, are compared with the GP6 PostgreSQL planner. GP6 uses serial Append, so the parallel columns compare the available execution strategies rather than identical plan shapes.

Cloudberry build	ORCA / GP6 ORCA	PostgreSQL serial / GP6 PostgreSQL	PostgreSQL parallel / GP6 PostgreSQL	Fallback / GP6 PostgreSQL
Unmodified upstream main	1.70×	1.65×	1.43×	1.45×
Unmodified upstream REL_2_STABLE	1.61×	1.70×	1.41×	1.33×
3.0.0-devel + PR #2094	1.08×	1.12×	0.82×	0.96×
REL_2_STABLE + PR #2094 (experimental; known UPDATE failure)	1.14×	1.19×	0.91×	0.92×

In these measurements, unmodified main and REL_2_STABLE took 1.70× and 1.61× as long as GP6 with ORCA, respectively. Even with PostgreSQL Parallel Append, they took 1.43× and 1.41× as long as the GP6 PostgreSQL planner. The PR #2094 builds narrow the ORCA gap and show lower median times than GP6 in the PostgreSQL parallel mode.

These are provisional laptop measurements with the build differences documented above, not an isolated cross-version regression measurement. The experimental REL_2_STABLE backport also has a known UPDATE correctness failure.

Patch that I used for measures REL_2_STABLE + #2094 attached as a file.
rel2-pr2094-backport.patch

Related issues

Add ORCA intra-segment parallel scan support for partitioned AO tables

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

[yjhjstz]

Thanks for the very thorough report, @Alena0704. Your code reading matches what is on main today, and the conclusion is right: this is a missing capability in ORCA, not a cost-model decision.

Current state

• PR orca: implement intra-segment parallel table scan support #1398 deliberately scoped intra-segment parallelism to plain CLogicalGet. CLogicalDynamicGet::PxfsCandidates() still only offers ExfDynamicGet2DynamicTableScan and ExfExpandDynamicGetWithForeignPartitions, so ORCA never generates a parallel alternative for a partitioned table. ExtractParallelWorkersFromDXL() returning 1 for EdxlopPhysicalDynamicTableScan is consistent with that, not a separate bug.
• The fallback you observed with optimizer_enable_dynamictablescan=off is expected. With that xform disabled, CLogicalDynamicGet has no physical implementation, ORCA fails to find a plan, and we fall back to the PostgreSQL planner. It happens to produce Parallel Append here, but it is not a supported way to ask ORCA for a parallel plan.
• This gap is part of the roadmap in discussion [Proposal] Enhanced ORCA Parallel Planning to Align with PostgreSQL Planner #1316, and dynamic scans are the natural next milestone after orca: implement intra-segment parallel table scan support #1398.

I already have a draft PR for this and will open it shortly. It follows the second direction you described: reuse the dynamic-scan-to-Append translation and the existing Parallel Append executor, instead of making DynamicSeqScan parallel-aware. The main reasons:

1. CTranslatorExprToDXL::PdxlnDynamicScanToAppend() already emits the Append with the partition selector ids of the scan, so join-driven dynamic partition pruning is preserved.
2. Parallel Append over Parallel Seq Scan children gives both whole-partition scheduling and intra-partition parallelism. The AO parallel scan already splits work by segment file, so a single surviving partition still parallelizes, which a shared partition counter inside DynamicSeqScan would not do.
3. No new DSM walker is needed in execParallel.c; Append and SeqScan are already handled.

[Alena0704]

Good! When it is ready, I'll be happy to review it!

[Alena0704]

After merging commits for this feature, I measured again and it looks significantly better. I don't see any remaining problems here, so I'm closing this discussion and the follow-up issue. The report measurement is bellow.

October 23, 2026. Comparison: Cloudberry main, Apache REL_2_STABLE with the Parallel Append backport, and OpenGPDB.

Tables, partitions, and AO file sizes

Each table contained the same 6,000,000-row dataset, distributed by id across 3 primary segments, with 13 daily AO row-oriented partitions covering January 1–13, 2020. The partition count was fixed in every test. Total AO data size was approximately 540.6 MB per table; the tests varied how these data were split into physical files.

The same DDL and generated data were used for all three layouts. Example for the one-file layout:

SET gp_appendonly_insert_files = 0;

CREATE TABLE public.ao13 (
    id bigint, d date, col1 int, col2 int, pad text
)
WITH (appendonly=true, orientation=row)
DISTRIBUTED BY (id)
PARTITION BY RANGE (d) (
    START ('2020-01-01'::date)
    END ('2020-01-14'::date)
    EVERY ('1 day'::interval)
);

INSERT INTO public.ao13
SELECT g, '2020-01-01'::date + (g % 13),
       g % 97, g % 89, repeat('x', 50)
FROM generate_series(1, 6000000) g;

ANALYZE public.ao13;

The two files4_* tables are in schema ao_files_20261015.

Table	gp_appendonly_insert_files	gp_appendonly_insert_files_tuples_range	Populated files per partition/segment	Mean physical file size, MB
public.ao13	0	Not used	1	13.86
files4_default	4	100000	2	6.93
files4_balanced	4	10000	4	3.47

The resulting totals were 39, 78, and 156 populated AO files. Sizes above are averages in decimal MB; individual files were not all equal in size.

Each partition/segment held 153,155–154,613 rows. With a 100,000-row rotation interval, only two files were populated: 100,000 rows in one and 53,155–54,613 in the other, despite the configured four-file limit. A 10,000-row interval rotated writes across all four files, producing three files of 40,000 rows and one of 33,155–34,613 rows.

OpenGPDB used concurrent insert transactions to reproduce the same file layouts: two writers split rows at local rank 100,000; four writers used ((local_rank - 1) / 10000) % 4.

The query counted the entire table, scanning all 13 partitions without a date filter. Example for the four-file layout with ORCA Parallel Append enabled:

SET optimizer = on;
SET enable_parallel = on;
SET max_parallel_workers_per_gather = 4;
SET optimizer_enable_dynamictablescan = on;
SET optimizer_disable_dynamic_table_scan = off;
SET optimizer_enable_parallel_append = on;

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF)
SELECT count(*) FROM ao_files_20261015.files4_balanced;

The off comparison set optimizer_enable_parallel_append=off in the same binary. The other layouts used the corresponding table names above. OpenGPDB used its ORCA Dynamic Seq Scan baseline. Every result was 6,000,000.

Plan verification: all 132 accepted ORCA-on plans for main and Apache REL_2_STABLE across -O0/-O3, warm and cold cache, contained an executed Parallel Append node with nonzero actual rows and loops, Gather Motion 12:1, and Optimizer: GPORCA. This covers 120 measured runs and 12 warm-up runs. All 132 corresponding ORCA-off plans contained Dynamic Seq Scan and Gather Motion 3:1, with no Parallel Append.

Excerpt from an actual four-file, cold-cache -O3 plan on main:

Finalize Aggregate (actual rows=1 loops=1)
  ->  Gather Motion 12:1  (slice1; segments: 12) (actual rows=12 loops=1)
        ->  Partial Aggregate (actual rows=1 loops=1)
              ->  Parallel Append (actual rows=495974 loops=1)

Measurement conditions

Ryzen 7 3750H, 4 cores / 8 logical CPUs, approximately 13 GiB RAM, NVMe SSD; one coordinator and three primary segments, shared_buffers=16MB per instance. GCC/G++ 11.4.0, -O0 -g or -O3 -g, with debug and assertions enabled.

Warm cache: one warm-up per case, excluded from results, followed by five measured runs in a persistent psql session. Cold cache: five measured runs, each after stopping clusters, clearing the OS cache, and verifying zero resident AO data pages immediately before the query. The SSD hardware cache was not cleared. Results below are median Execution Time in milliseconds, excluding planning, cache clearing, and startup.

Performance results

Four populated AO files per partition/segment:

Build / ORCA mode	-O0 warm	-O0 cold	-O3 warm	-O3 cold
Cloudberry main, Parallel Append off	774.271	938.675	302.049	411.082
Cloudberry main, Parallel Append on	584.411	717.117	215.208	297.893
Apache REL_2_STABLE + backport, off	1148.011	1257.391	351.606	459.310
Apache REL_2_STABLE + backport, on	873.218	917.522	254.689	331.698
OpenGPDB, Dynamic Seq Scan	992.596	1160.617	380.924	537.131

Effect of file layout, -O3 with warm cache:

Build / ORCA mode	1 file	2 files	4 files
Cloudberry main, Parallel Append off	264.799	282.504	302.049
Cloudberry main, Parallel Append on	219.252	237.344	215.208
Apache REL_2_STABLE + backport, off	384.598	351.883	351.606
Apache REL_2_STABLE + backport, on	265.241	266.096	254.689
OpenGPDB, Dynamic Seq Scan	380.350	380.763	380.924

For four-file layouts, enabling Parallel Append reduced median execution time by 23.6–28.8% on main and 23.9–27.8% on Apache REL_2_STABLE, depending on optimization level and cache state. Changing the number of AO files alone did not produce a consistent monotonic speedup. These results describe five repetitions on this host; comparisons between builds also include differences in PostgreSQL versions and AO implementations.

REL_2_STABLE backports

The tested five-commit series in open-gpdb/cloudberry REL_2_STABLE, in application order:

1. Implement Parallel Append in ORCA.
2. Fix DXL translation for ParallelAppendTableScan under SET queries.
3. Fix CPhysicalParallelAppendTableScan::FValidContext.
4. Fix parallel worker extraction for ParallelAppend.
5. Add the missing <array> include in PAX.