Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#1,839 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
68/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
c, postgresql, sql

調査の方向性

DXL-to-PlannedStmt 変換パスから始め、PlanSlice->directDispatch.contentIds がどのように設定されるかを調べ、src/backend/cdb/cdbmutate.c の MergeDirectDispatchCalculationInfo および directdispatch.c の系譜と比較します。optimizer をオンとオフにした状態で、3 セグメントの SQL 例を使って問題を再現し、IN 述語と明示的な OR 述語の両方を含めます。完了の条件は、複数値の分散キー述語について、ORCA が対象セグメントの和集合に対してのみ報告し、dispatch することです。

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
C
スター
1.4k
フォーク
248
平均マージ
4日 10時間
マージ済み PR(30日)
40

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/cloudberry のほかの issue

apache/cloudberry の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。