[Bug] ORCA misses direct dispatch for multi-value predicates (IN / OR of equalities) on the distribution key

Comienza con la ruta de traducción de DXL-to-PlannedStmt e inspecciona cómo se rellena PlanSlice->directDispatch.contentIds, comparándola con MergeDirectDispatchCalculationInfo en src/backend/cdb/cdbmutate.c y con el linaje de directdispatch.c. Reproduce el problema usando los ejemplos SQL de tres segmentos, con el optimizador activado y desactivado, incluidos predicados tanto IN como OR explícito. Se considera terminado cuando ORCA informa y distribuye únicamente al conjunto unión de los segmentos objetivo para predicados con múltiples valores sobre la clave de distribución.

Apache Cloudberry version

All versions

What happened

For a predicate that restricts the distribution key to a small set of
constants, e.g. WHERE dist_key IN (c1, c2), GPORCA only performs direct
dispatch when ALL values happen to hash to the SAME segment. If the values
hash to different segments, ORCA gives up entirely and dispatches the slice
to every segment, while the Postgres planner correctly direct-dispatches to
the union of the target segments.

Results are correct — this is a performance issue (missed direct dispatch),
not a wrong-results bug. I'm filing it as a bug rather than a feature request
because the optimizer side already emits the complete multi-value dispatch
info into the DXL plan, and the DXL-to-PlannedStmt translator silently drops
it (details in "Anything else").

What you think should happen instead

ORCA should dispatch to the union of the segments the constants hash to,
like the Postgres planner does (see MergeDirectDispatchCalculationInfo in
src/backend/cdb/cdbmutate.c / directdispatch.c lineage). For the
reproduction below, the planner produces:

  Gather Motion 2:1  (slice1; segments: 2)
  INFO:  (slice 1) Dispatch command to PARTIAL contents: 1 2

while ORCA produces:

  Gather Motion 3:1  (slice1; segments: 3)
  INFO:  (slice 1) Dispatch command to ALL contents: 0 1 2

The infrastructure already supports this: PlanSlice->directDispatch.contentIds
is a List, and the dispatcher handles multiple content ids today (the planner
populates it with more than one; so does ORCA's own raw-values path for
gp_segment_id IN (...) predicates on randomly distributed tables).

How to reproduce

On a 3-segment demo cluster:

create table t_dd (a int, b text) distributed by (a);
insert into t_dd select i, 'x' from generate_series(1, 10) i;
-- on my cluster: a=1 -> seg1, a=2,3 -> seg0, a=5 -> seg2
-- (cdbhash of int is deterministic, so a 3-segment cluster gets the same mapping)

set gp_test_print_direct_dispatch_info = on;

set optimizer = on;
explain (costs off) select * from t_dd where a in (1, 5);
--  Gather Motion 3:1  (slice1; segments: 3)      <-- all segments
select * from t_dd where a in (1, 5);
--  INFO:  (slice 1) Dispatch command to ALL contents: 0 1 2

explain (costs off) select * from t_dd where a in (2, 3);
--  Gather Motion 1:1  (slice1; segments: 1)      <-- works, but only because
--                                                    both values hash to seg0
set optimizer = off;
explain (costs off) select * from t_dd where a in (1, 5);
--  Gather Motion 2:1  (slice1; segments: 2)      <-- planner dispatches to
select * from t_dd where a in (1, 5);             --    the union {seg1, seg2}
--  INFO:  (slice 1) Dispatch command to PARTIAL contents: 1 2

The explicit OR form (a = 1 or a = 5) behaves the same way.

Operating System

Rocky Linux 9.5

Anything else

No response

Are you willing to submit PR?

• Yes, I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct.