この記事は後半です。前半は Qiita にあります: 2回目だけ5ミリ秒で見抜かれたpgrust、ClickBench削除の境界線
pgrust の件でまず押さえたいのは、問題にされたのは「キャッシュがあること」そのものではない、という点だ。ClickBench も ClickHouse の query condition cache も、中間データの再利用自体は認めている。許されるのは、同じフィルタ条件をもう一度評価するために、どこを読まなくてよいかを覚えておくことだ。読んだ答えを丸ごと返すことではない。
画像: github.com より
だから争点は、pgrust が持っていた再利用が、条件の判定なのか、答えそのものなのか、そこにある。0.4-preview では、43 クエリだけを前提にした machinery と、前回の実行で得た verdict を hot run で使い回す構図が指摘された。これが事実なら、再実行のたびに計算しているのではなく、すでに出た結論を返していることになる。ベンチマークの数字としては、かなりまずい。
画像: clickhouse.com より
後続の 0.4-beta では、pgrust 自身がキャッシュの内訳をかなり細かく開示している。condition cache、dictionary filter cache、zone map cache が別々にあり、どれも設定で切り替えられる。ここだけ見ると、かなり誠実に見える。だが、問題は各キャッシュの位置だ。
condition cache は、ある predicate に対して granule ごとに「ひとつでも一致行があるか」を覚える。ClickHouse の説明と同じで、0 bit ならその granule を飛ばせる。これは中間情報の再利用だ。一方で、pgrust の指摘では、Q20、Q21、Q23 の hot run が「pure fold over cached verdicts — ZERO columns touched」とされている。列を読まずに verdict だけ折りたたむなら、それはもはや走査の短縮ではなく、答えの再生に近い。
この違いは、数字の落ち方にも表れている。あるクエリは初回 10.8 秒で、2 回目が 11 ミリ秒、3 回目が 5 ミリ秒。別のクエリは 1.65 秒から 4 ミリ秒になる。再起動するとまた 11 秒台に戻る。ふつうの warm cache なら、ここまで極端には動かない。少なくとも「同じ条件をもう一度評価したから速い」という説明だけでは足りない。
ここで大事なのは、ClickBench の hot run 自体は不正ではないことだ。むしろ複数回実行して、温まった状態を測る前提で設計されている。だから「2回目が速い」だけなら、普通は問題にならない。
ただし、速くなる理由が何かで話が変わる。ClickBench のルール上、クエリ結果キャッシュに近いものは無効化すべきだし、少なくとも benchmark の入力に対して一意に答えを引く lookup table のような動きは避けるべきだ。pgrust 側は 0.4-beta で「このキャッシュは中間データだ」と説明を足したが、削除された旧エントリでは、ベンチマーク専用の分岐と前回結果の再利用が同時に疑われた。ここが一線だった。
さらに、対象外の SQL にはかなり露骨にエラーを返す。statement over columnar relation "hits" is not served のように、対応範囲外を正面から拒否する。これは広い SQL を受ける DB というより、43 個の形を最短でさばく機械に見える。汎用エンジンとしての評価と、ベンチマーク専用の最短経路の評価が、ここで混線した。
自分なら、pgrust を性能の話として見るより、設計の割り切り方を見る材料として使う。特に、条件キャッシュや zone map のような「読まなくていい範囲を覚える」仕組みは、実運用でも意味がある。反対に、ベンチマークの形に合わせて分岐を増やし、再実行で答えをほぼ返すだけの経路が入ると、比較の土台は崩れる。
この件が教えるのは、キャッシュは善でも悪でもなく、位置がすべてだということだ。クエリの手前に置けば最適化、答えの直前に置けば近道、答えの後ろに置けば数字の改ざんに見える。pgrust はその境目でつまずいた。2回目だけ 5 ミリ秒、という見え方は、その境目をかなりはっきり示している。
