1. insert on conflict do nothing/update需求-合入评审（云和恩墨） a. allow_concurrent_tuple_update 参数和 lockwait_timeout 参数为什么这么设置，解释清楚。客户期望的表现也调查清楚 --- 此语法就是upsert的另一种实现形式，在原有的upsert流程上稍加适配就可以支持，唯一不同的就是ON CONFLICT conflict_target中conflict_target比较灵活，需要新增处理流程，其它流程通用。已修改，限制条件和UPSERT基本一致。 b. 补充一下在 insert 、 update 、 update nothing 时， before/insert insert 、 before/insert update 的触发器执行情况，是否符合预期 --- 在fastcheck中已增加相应测试用例 c. 补充实现上，和upsert的具体差异以及为什么有这些差异 --- 已修改，共用upsert流程，只做了少许适配 2. 支持全局sequence cache（云和恩墨） a. 测试gs_dump导出全局cache是否正常 --- 已经增加gs_dump的适配代码，并做了相应测试 b. 全局hash桶的内存改成lazy init，第一次创建global sequence时再分配内存 --- 已经修改为lazy init方式。 c. key里面的db_oid看起来没有作用，确认是否有用到 --- 确认没有使用，已去除。 d. 用例测试下，session 和 global 来回切换 --- 已经测试，符合预期 e. 用例测试下，10并发场景，并发更新global sequence和session sequence，性能相差多少 --- 已经测试 f. 用例测试下，多次反复重启之后，global sequence的表现是否符合预期 --- 已经测试，符合预期 pengjiong<pengjiong1@huawei.com> 在 2025年12月12日 周五 17:13 写道： 【2025.12.12】 1. insert on conflict do nothing/update需求-合入评审（云和恩墨） a. allow_concurrent_tuple_update 参数和 lockwait_timeout 参数为什么这么设置，解释清楚。客户期望的表现也调查清楚 b. 补充一下在 insert 、 update 、 update nothing 时， before/insert insert 、 before/insert update 的触发器执行情况，是否符合预期 c. 补充实现上，和upsert的具体差异以及为什么有这些差异 d. 下次继续评审设计遗留问题 2. 支持全局sequence cache（云和恩墨） a. 测试gs_dump导出全局cache是否正常 b. 全局hash桶的内存改成lazy init，第一次创建global sequence时再分配内存 c. key里面的db_oid看起来没有作用，确认是否有用到 d. 用例测试下，session 和 global 来回切换 e. 用例测试下，10并发场景，并发更新global sequence和session sequence，性能相差多少 f. 用例测试下，多次反复重启之后，global sequence的表现是否符合预期 g. 相关问题邮件回复即可，用例测试在checkin时补充说明，无需再次评审设计 3. 优化 nbtree 单列范围查询设计评审 (邮储-刘宇浩) 评审通过 发件人: pengjiong <pengjiong1@huawei.com> 发送时间: 2025年12月12日 10:03 收件人: sqlengine@opengauss.org 主题: [SQLEngine] SQLEngine SIG 会议详情: 1. insert on conflict do nothing/update需求-合入评审（云和恩墨） 2. 支持全局sequence cache（云和恩墨） 3. 优化 nbtree 单列范围查询设计评审 (邮储-刘宇浩) 发起人: totaj 会议平台: WELINK 会议ID: 966670905 会议链接: https://meeting.huaweicloud.com:36443/#/j/966670905 Etherpad: https://etherpad.opengauss.org/p/SQLEngine-meetings