同结构分区表 join 时 merge group by 算子导致的正确性问题

问题现象

问题的现象是生成如下的计划时，12 号 table scan 有数据但是输出了 0 行导致最终结果集为空。

| ===================================================================
|ID|OPERATOR                        |NAME          |EST. ROWS|COST|
-------------------------------------------------------------------
|0 |PX COORDINATOR MERGE SORT       |              |99       |1136|
|1 | EXCHANGE OUT DISTR             |:EX10001      |99       |1053|
|2 |  SORT                          |              |99       |1053|
|3 |   MERGE GROUP BY               |              |99       |937 |
|4 |    EXCHANGE IN MERGE SORT DISTR|              |99       |923 |
|5 |     EXCHANGE OUT DISTR (HASH)  |:EX10000      |99       |840 |
|6 |      PX PARTITION ITERATOR     |              |99       |840 |
|7 |       MERGE GROUP BY           |              |99       |840 |
|8 |        MERGE JOIN              |              |130      |825 |
|9 |         SORT                   |              |135      |214 |
|10|          TABLE SCAN            |a             |135      |53  |
|11|         SORT                   |              |297      |518 |
|12|          TABLE SCAN            |b(idx_sno_bno)|297      |115 |
===================================================================

Outputs & filters:
-------------------------------------
  6 - output([a.bill_no], [a.status], [a.create_time]), filter(nil),
      force partition granule.
  7 - output([a.bill_no], [a.status], [a.create_time]), filter(nil),
      group([a.bill_no]), agg_func(nil)

要满足如下条件：

1. 有一个下推的 merge group by 算子，该算子的孩子不是 sort 算子，并且该算子不计算 distinct，对应上面的7号算子。

2. 这个 merge group by 算子的 parent 是一个 granule iterator 算子，对应上面的 6 号算子，并且该算子没有被标记为 partition wise。explain extended 会展示 granule iterator 算子的标记，上面计划中可以看到 6 号算子打了 force partition granule 的标记。

3. merge group by 下面有一个 partition-wise 的 join，即 join 两侧都不存在 exchange 算子，对应上面的 8 号算子。

关键诊断信息

触发条件

要满足如下条件：

1. 有一个下推的 merge group by 算子，该算子的孩子不是 sort 算子，并且该算子不计算 distinct，对应上面的7号算子。

2. 这个 merge group by 算子的 parent 是一个 granule iterator 算子，对应上面的 6 号算子，并且该算子没有被标记为 partition wise。explain extended 会展示 granule iterator 算子的标记，上面计划中可以看到 6 号算子打了 force partition granule 的标记。

3. merge group by 下面有一个 partition-wise 的 join，即 join 两侧都不存在 exchange 算子，对应上面的 8 号算子。

问题原因

这里为 granule iterator 少打了 partition-wise 的标记，导致该算子认为自己下面只有一个 table scan，没有为右侧的 12 号 table scan 算子设置扫描任务。 少打标记的原因是有一个 BUG，当 GI 被上提到一个下推的 merge group by 上面，这个 merge group by 不用计算 distinct 并且下面不是 sort 算子时，一定不会为 GI 打上 partition-wise 的标记。

问题的风险及影响

可能导致输出错误结果，预期结果集不为空，实际为空。

影响租户

影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户，对于 SYS 租户无影响。

影响版本

OceanBase 数据库企业版 V2.2.77 GA（oceanbase-2.2.77-20210508211731）及之后版本、V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220419）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本、V4.1.0 GA（oceanbase-4.1.0.0-100001122023040322）及之后版本。

解决方法

• 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V2.2.77 BP19（oceanbase-2.2.77-119000122024060513）、V3.2.3 BP9（oceanbase-3.2.3.3-109000182023071410）、V3.2.4 BP5（oceanbase-3.2.4.5-105000012023081513）、V4.1.0 BP3（oceanbase-4.1.0.2-103000072023081111）。

• 应急办法：使用 Hint /*+ USE_HASH_AGGREGATION */，将 merge group by 改为 hash group by。