Skip to content

orca: fall back on replicated CTE only when consumed in 2+ slices#398

Draft
Alena0704 wants to merge 3 commits into
OPENGPDB_STABLEfrom
relax-shareinput-walker
Draft

orca: fall back on replicated CTE only when consumed in 2+ slices#398
Alena0704 wants to merge 3 commits into
OPENGPDB_STABLEfrom
relax-shareinput-walker

Conversation

@Alena0704

Copy link
Copy Markdown
Contributor

orca: fall back on replicated CTE only when consumed in 2+ slices

Only a replicated CTE consumed in 2+ different slices hangs, not any
cross-slice consumer. Narrow the fallback check to that case

@Alena0704
Alena0704 marked this pull request as draft July 3, 2026 11:45
Only a replicated CTE consumed in 2+ different slices hangs, not any
cross-slice consumer. Narrow the fallback check to that case.
@Alena0704
Alena0704 force-pushed the relax-shareinput-walker branch from 6eb53c2 to 3d01cbc Compare July 12, 2026 23:12
FHasCrossSliceReplicatedCTEConsumer modeled slice assignment on the
ORCA CExpression tree, before DXL/Plan translation.
@Alena0704
Alena0704 force-pushed the relax-shareinput-walker branch from ac411ad to c52c0a4 Compare July 13, 2026 08:07
…verage

A cross-slice ShareInputScan only executes correctly when its producer
and consumer gangs run on the same set of segments: the writer on each
producing segment waits for an ack from a reader on that same segment
(nodeShareInputScan.c). When the two slices cover different segment sets
-- e.g. a DISTRIBUTED REPLICATED CTE materialized on all segments but
consumed in a single-segment slice under a Gather 1:1 -- a writer waits
for an ack that never arrives and the query hangs to statement_timeout.

Detect this on the final plan, where per-slice segment coverage is
actually known. apply_shareinput_xslice() already walks the plan with a
motId stack; carry a parallel stack of each slice's coverage key
(SINGLETON segindex, or "all segments", mirroring how FillSliceTable()
sizes an ORCA plan's gangs). When a share is marked cross-slice, compare
the producer's and consumer's coverage; if they differ (and the share is
not a QD share, which pass 4 relocates onto the QD), set a hazard flag.
optimize_query() then discards the ORCA plan and lets the Postgres
planner plan the query.
@Alena0704
Alena0704 force-pushed the relax-shareinput-walker branch from c52c0a4 to 58c9933 Compare July 13, 2026 10:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants