Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,839 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 3 ngày

@zhangwenchao-123 đang làm issue này rồi.

Từ ngày 15/7/2026.

  • #1852 của @zhangwenchao-123 — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
68/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
c, postgresql, sql
Lĩnh vực
backend, databases, distributed-systems

Hướng nghiên cứu

Bắt đầu với đường dẫn dịch DXL-to-PlannedStmt và kiểm tra cách PlanSlice->directDispatch.contentIds được điền, so sánh với MergeDirectDispatchCalculationInfo trong src/backend/cdb/cdbmutate.c và dòng phát triển của directdispatch.c. Tái hiện vấn đề bằng các ví dụ SQL ba segment, với optimizer được bật và tắt, bao gồm cả các vị từ IN và OR tường minh. Được xem là hoàn tất khi ORCA chỉ báo cáo và dispatch đến hợp của các segment đích đối với các vị từ có nhiều giá trị trên khóa phân phối.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

type: Bug
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
Ngôn ngữ chính
C
Star
1.4k
Fork
260
Merge trung bình
4 ngày 13 giờ
Pull request đã merge (30 ngày)
56

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/cloudberry

Tất cả issue của apache/cloudberry

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.