DeepSeek总结的PR#23665改进TPC-H dbgen进度报告、ETA稳定性及生成性能

kryonix此PR将CALL dbgen(…)接入进度条和ETA预计剩余时间基础设施并显著提升执行速度尤其是在较大规模因子scale factor和持久化数据库中。此前TPC-H生成可能在长时间内没有任何有意义的进度反馈。DuckDB已有CLI进度条支持但TPC-H的dbgen路径并未使用它。此PR将dbgen接入进度系统并同时跟踪已生成工作和已刷盘工作使得进度条在存储阶段也能持续前进而不是从部分进度直接跳转到完成。在处理进度报告时ETA行为也需要关注。之前的终端ETA使用了卡尔曼估计器这对于相对平滑的进度信号效果较好。但TPC-H生成具有突发性并行工作线程以不均等的时间完成数据块持久化存储引入了刷盘阶段并且进度可能以较大步长到达。这导致ETA对最新样本反应过度并剧烈跳动。此PR用更简单的估计器替换了终端ETA逻辑使用已耗进度的稳定基线使用最近观察到的进度速率作为修正对修正进行限幅使得短时突发不会主导估计值平滑预测的完成时间戳允许后续估计值逐渐向外移动而不是向上跳跃。结果虽然不那么“聪明”但更具可预测性ETA仍然会在工作负载速度变化时进行调整但不再随着每次进度更新而剧烈摆动。不过我对这个改动并不执着我们也可以直接恢复到之前的方式。此PR更大部分重写了TPC-H dbgen的热路径追加逻辑。旧实现首先生成DBGEN行结构体然后将这些值复制到DuckDB向量中。这带来了额外的行物化、额外的字符串处理以及可避免的日期格式化/解析工作。新路径直接生成到DuckDB数据块中。具体而言它直接将TPC-H日期偏移量写为DuckDB日期避免中间使用order_t、line_t、part_t等追加结构体避免重复计算分布字符串长度在安全的情况下直接引用稳定的DBGEN分布/文本池字符串仅在DBGEN可能修改的值上保留可写的向量自有字符串存储调整了并行生成的粒度更早地刷新持久化追加状态以保持内存使用受控。最终结果是运行时大幅提升模式查询修改前修改后加速比内存模式dbgen(sf1)1.249s0.259s4.8倍内存模式dbgen(sf10)12.818s1.274s10.1倍持久化模式dbgen(sf10)46.752s4.159s11.2倍在20GB内存限制下SF 1000现在大约在470秒内运行完成。我不愿意等待旧实现完成但可以肯定它会慢得多。底层重写的主要实际收益是减少了中间工作、减少了拷贝、减少了字符串/日期转换开销并且对存储追加路径的压力大大降低。在amd 8845主机 windows实际测试C:\dduckdb0712 DuckDB v1.6.0-dev10612 (Development Version, 2009475939) Enter .help for usage hints. memory D load tpch; memory D .timer on memory D call dbgen(sf3); Run Time (s): real 2.478 user 15.296875 sys 1.906250 memory D .exit C:\dduckdb154 DuckDB v1.5.4 (Variegata) Enter .help for usage hints. memory D install tpch; memory D .timer on memory D call dbgen(sf3); ┌─────────┐ │ Success │ │ boolean │ └─────────┘ 0 rows Run Time (s): real 7.573 user 26.296875 sys 3.343750 memory D .exit