阅读官方文档，发现在506.0版本中引入了一个新特性，叫“支持ubtree批量插入索引”
官方文档链接
当以下任何一个场景满足所有的约束条件时，建议打开GUC参数batch_insert_index_types并设置为"rcr_ubtree"以提升批量插入索引性能：
场景1：使用JDBC连接数据库，通过java的批量插入数据接口executeBatch进行批量插入索引；
场景2：执行语句insert into t1 select * from t2，其中t1和t2表schema相同，t1表包含索引，此语句支持在t1表上批量插入索引；必须在批量插入表数据的前提下才会批量插入索引（explain verbose命令可以查看是否对表数据做批量插入，Batch Insert代表是批量插入）。满足这些前提后，打开批量插入索引开关就会执行批量插入索引；
场景3：执行语句COPY FROM（示例：COPY t1 FROM ‘file.csv’ delimiter ‘,’ csv header），其中t1和file.csv文件中的schema相同，t1表包含索引，此语句支持在t1表上批量插入索引。
约束1：插入的索引类型为UBTree RCR索引；
约束2：插入数据不递增（插入数据递增会利用缓存，即最后一页，这种情况下批量插入索引无性能提升）；
约束3：不是SMP的批量索引插入。
此特性在以下三个场景会影响性能：
如果批量插入数据是递增的（违反约束2），关闭批量插入功能后，会插入到最右缓存中，性能较好。这种场景下开启批量插入功能会导致性能出现轻微劣化。
在执行持续的批量插入时，索引会逐渐变大，进而导致批量插入性能有所下降。
批量插入数据过于分散导致缓存页面命中率过低，或者运行内存过小的场景下，开启批量插入功能会导致性能出现较大幅度劣化。
如果性能劣化幅度较大，建议设置GUC参数batch_insert_index_types为""，关闭该功能，性能劣化问题即可恢复。
如果需要技术支持工程师定位原因，可以设置GUC参数logging_module=‘on(BIINDEX)’，打开批量插入索引的日志打印，执行几分钟批量插入直到日志中出现BIINDEX字符串为止。
其实这个特性的原理简单来说，就是中间加了层索引的缓存页面，可以提前将索引进行排序，加快插入索引的速度（与之相对的其实就是批量数据插入时的单行索引插入）。
这个功能在GaussDB中是默认开启的，创建的索引默认就是RCR索引。
指定创建PCR索引会报错GAUSS-40615: Extreme redo does not support pcr's ubtree.（Extreme Redo不支持 pcr's ubtree。）（没找到任何有关Extreme redo的说明）。
batch_insert_index_types默认为rcr_ubtree。
