这将从基准中移除 pgrust 条目（在 #1163 中添加，在 #2106 中更新到 v0.4-preview）。它报告的结果是由专门为 43 个 ClickBench 查询编写的机器产生的，并且它的热运行重放了上一次运行的缓存答案。这两者都违反了规则：查询结果缓存和接近管道末尾的缓存必须被禁用，而该条目标记为 tuned: no，尽管它是针对这些确切的查询进行调优的。以下所有内容都经过与发布的 v0.4-preview 版本二进制文件（pgrust.com/downloads/v0.4-preview/，那个安装下载）以及公共 v0.3 源代码（github.com/malisper/pgrust）的验证。v0.4-preview 源代码没有发布；该二进制文件自我标识为 pgrust 0.3-beta。每个基准查询有一个手写内核。aarch64 发布的二进制文件嵌入了这些源路径：crates/gravity/backend/irprobe/src/q00.rs q01.rs q02.rs q03.rs q04.rs q06.rs q07.rs q12.rs q15.rs q16.rs q17.rs q18.rs q19.rs q20.rs q21.rs q22.rs q23.rs q24.rs q25.rs q27.rs q30.rs q31.rs q36.rs tpch_q01.rs。数字是 ClickBench 查询编号。调度到这些内核的计划匹配器发出拒绝信息，命名为基准，例如：clickbench group count: filter is not `k <> 0`，clickbench phrase-min: the third column is not count(*)，clickbench t3 distinct: min(text) / LIKE need one text key, count(*) and the count order，clickbench frame: date_trunc unit is not minute，tpch q1: column 6 is not sum(price * (1 - discount) * (1 + tax))。还有一个环境开关字面上名为 PGRUST_GRAVITY_Q20_VARIANT。公共 v0.3 源代码确认了设计：crates/backend/executor/sqe/rig/plans/clickbench.ron 在其头部描述为“所有 43 个 ClickBench 查询的手工物理计划”，而 queries-clickbench.sql（逐字的基准 SQL）被编译进 executor crate 里，使用 include_str!。该文件将 Q0, Q1, Q2, Q3, Q6, Q19 和 Q29 分类为 MetadataAnswer（从每部分统计数据回答，无需扫描），指出 Q19 的“答案行是从谓词常量重构的”，Q29 是代数重写 SUM(x+k) = SUM(x) + k*COUNT，后面跟着一个元数据答案，Q18 依赖于持久化的派生列“带有烘焙位宽 26/6/20”。Q28 的正则表达式是一个单条硬编码表（HOST_EXTRACT_PATTERN = ^https?://(?:www\. )?([^/]+)/.*$），策划者的评论写道：“43 的唯一 HAVING 形状：COUNT(*) > k”。热运行是结果缓存，对于 Q20、Q21 和 Q23，该计划的注释说：“热重复 = 纯折叠缓存判决 — 零列被触及；选择即答案。”发布二进制文件上的 EXPLAIN 报告 SQE: engine (family: windowreplay) 对于 Q20 和 family: metaanswer 对于 Q1，扫描标记为从未执行。使用该条目的脚本和配置，在一台 96 核 Graviton (Neoverse-V2) 机器上进行本地测量，并执行真正的冷周期（停止、丢弃缓存、启动），就像驱动程序所做的那样：查询冷 2 次运行 第三次运行 相同形状，新的常量，第一次运行 Q20 URL LIKE '%google%' 10.8 秒 11 毫秒 5 毫秒 '%rambler%' : 283 毫秒，然后 12 毫秒，4 毫秒 Q17 GROUP BY UserID, SearchPhrase LIMIT 10 1.65 秒 4 毫秒 15 毫秒 Q33 GROUP BY URL ORDER BY c DESC LIMIT 10 2.38 秒 213 毫秒 108 毫秒 第二次重启将 Q20 恢复到 11.2 秒，然后 3 毫秒。该引擎的真实温暖速度对于子字符串扫描是几百毫秒，这大约是 ClickHouse 在相同硬件上执行的速度。发布的热数（Q20 为 7 到 23 毫秒）是对上一次运行判决的重放。v0.2 提交（#1163）披露了一个类似的缓存（pgrust.condition_cache = on）并提供关闭的选项。v0.4 更新移除了该 README 和设置。现在没有配置可以禁用缓存：即使 pgrust.gravity_entry = off 和 pgrust.condition_cache = off，重复的 LIKE 仍然返回 3 到 4 毫秒。超出 43 种形状的查询被拒绝。该引擎对列式表没有一般的执行路径。微扰的基准查询会以错误结束：ERROR: sqe: statement over columnar relation "hits" is not served，错误详细信息显示：“sqe 引擎服务列式形状没有回退；未提供的形状会发出响亮的失败，而不是缓慢运行”。67 个接近基准的探测中有 20 个和 49 个扰动变体中有 3 个被拒绝，包括：SELECT MIN (URL) FROM hits; SELECT COUNT ( * ) FROM hits WHERE URL = ' http://holodilnik.ru/ ' ; SELECT AVG (UserID + 1 ) FROM hits; SELECT SUM (ResolutionWidth * 2 ) FROM hits; SELECT MAX (length(URL)) FROM hits; SELECT COUNT ( * ) FROM hits WHERE strpos(URL, ' google ' ) > 0 ; SELECT COUNT ( * ) FROM ( SELECT UserID FROM hits GROUP BY UserID) t; SELECT SearchPhrase, COUNT ( * ) AS c FROM hits WHERE SearchPhrase <> ' ' GROUP BY SearchPhrase HAVING SUM (IsRefresh) > 10 ORDER BY c DESC LIMIT 10 ; SELECT REGEXP_REPLACE(Referer, ' ^https?://(?:www \.)?([^/]+)/.*$ ' , ' \1 ' , ' g ' ) AS k, ...