)]}'
{
  "commit": "2dbc6f0fbc68ba2fda8643c716611f3ae615e962",
  "tree": "3ee4b79a0fe18a7e1fed312e42d1d4c27ee96361",
  "parents": [
    "150113e25b7e0e9d72b64027ed2e91d800d5dd6d"
  ],
  "author": {
    "name": "924060929",
    "email": "lanhuajian@selectdb.com",
    "time": "Thu Jun 04 22:12:03 2026 +0800"
  },
  "committer": {
    "name": "924060929",
    "email": "lanhuajian@selectdb.com",
    "time": "Thu Jun 04 22:12:03 2026 +0800"
  },
  "message": "[opt](local shuffle) cores-aware bucket upgrade gate\n\nThe upgrade gate compared raw instance count to bucket count, but the real\nquestion is whether the bucket parallelism already saturates the backend\u0027s\nexecution threads: local calibration (20M x 20M join, bucket gradient\n4/6/8/10/13 at 16 instances on an oversubscribed host) showed the bucket\nbaseline keeps improving with bucket count while the upgraded plan stays\nflat — once min(buckets, threads) is close to min(instances, threads), the\nextra local exchange is a pure cost (-9% to -22%).\n\nGate per worker on EFFECTIVE parallelism gain:\n  min(instances, threads) \u003e min(buckets, threads) * ratio\nwhere threads \u003d pipelineExecutorSize from the heartbeat (fallback cpuCores;\n\u003c\u003d 1 means not reported yet and the capacity is treated as uncapped). Every\nworker owning buckets must clear the bar (conservative min-gain). On normal\ndeployments (threads \u003e\u003d instances) this reduces exactly to the previous\nformula.\n\nUT 16/16, nereids_p0/local_shuffle 7/7 on 3 BEs.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "92925292f123300f1c2da5adf69edd3d705186a9",
      "old_mode": 33188,
      "old_path": "fe/fe-core/src/main/java/org/apache/doris/planner/AddLocalExchange.java",
      "new_id": "dcbabc856f20fa0fb66bbe773ec43341e7aa121d",
      "new_mode": 33188,
      "new_path": "fe/fe-core/src/main/java/org/apache/doris/planner/AddLocalExchange.java"
    }
  ]
}