问题现象
查询生成的计划中包含以下计划形态时会触发报错，计划错误分配了 2 号 PX PARTITION ITERATOR 算子。
drop table t1;
create table t1(c1 int, c2 int, c3 int) partition by hash(c1) partitions 2;
create index idx on t1(c2) global;
select /*+leading(a) use_nl(b) parallel(8) pq_distribute(b bc2host none)*/ a.*, b.c2 from t1 a, t1 b, t1 c where a.c1 = b.c2 and b.c2 = c.c1;
===================================================================
|ID|OPERATOR |NAME |EST. ROWS |COST |
------------------------------------------------------------------
| 0|EXCHANGE IN DISTR | |768476808000|347018265999|
| 1| EXCHANGE OUT DISTR | |768476808000|175402092762|
| 2| PX PARTITION ITERATOR | |768476808000|175402092762|
| 3| MERGE JOIN | |768476808000|175402092762|
| 4| SORT | |392040000 |2088894120 |
| 5| NESTED-LOOP JOIN | |392040000 |244632216 |
| 6| EXCHANGE IN DISTR | |200000 |99693 |
| 7| EXCHANGE OUT DISTR | |200000 |77361 |
| 8| PX BLOCK ITERATOR | |200000 |77361 |
| 9| TABLE SCAN |a |200000 |77361 |
|10| DISTRIBUTED TABLE SCAN|b(idx)|1980 |766 |
|11| TABLE SCAN |c |200000 |77361 |
==================================================================
关键诊断信息
触发条件
条件下压 NestLoop 右表使用全局索引扫描使用 DAS，并且分布式连接算法使用了 BC2HOST 时，连接后 sharding 继承了右表 match all 的属性，再和其它表进行分布式连接，且使用了 partition wise 的连接算法。
问题原因
条件下压 NestLoop 右表使用全局索引扫描使用 DAS，并且分布式连接算法使用了 BC2HOST 时，连接后 sharding 继承了右表 match all 的属性，再和其它表进行分布式连接，如果使用了 partition wise 的连接算法，分配 GI 时会出现问题。
影响租户
影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户，对于 SYS 租户无影响。
问题的风险及影响
计划生成失败，造成查询报错。
影响的版本
OceanBase 数据库企业版 V3.2.3 GA（oceanbase-3.2.3.0-20220419）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本。
解决方法
升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V3.2.3 BP8（oceanbase-3.2.3.3-108000062023041511）及之后版本。
通过
leading/index/use_hash等hint避免多表连接计划中出现条件下压nestloop右表使用DAS（右表使用全局索引时会使用 DAS）。 或者直接通过set _enable_dist_data_access_service=false;关闭DAS功能，直接关闭DAS对其它DML性能会有影响，需要评估后确定。
规避方式
通过 leading/index/use_hash 等 hint 避免多表连接计划中出现条件下压 nestloop 右表使用 DAS（右表使用全局索引时会使用 DAS）。
