[hackers-jp: 16] [HACKERS] Experimental ARC implementation

[Yutaka tanida]

谷田です。

Message-ID: <3FA67541.9020105 ＠ Yahoo.com>

の表題のメールからの一連のスレッドですが、興味深いです。これは２つの実デー
タ入りLRUキューと、２つの実データなしLRUキューを持つLRU派生のアルゴリズ
ムです。LRUよりも、いわゆる「巨大なSequential Scanがバッファをからにして
しまいパフォーマンスを劣化させる問題」に対応できていて、この種のbuffer
management without hintsの中でも優秀なものの一つです。

# 半年前に「やってみる」と言っていた人がいたが、今まで出てなかった
# ところを見ると逃げたな:-)

まあ、Janご本人も

> When playing with it please keep a few facts in mind. A 64MB cache 
> (shared_buffers=8192) needs about 10 minutes of full transaction load to 
> populate, in benchmark terms this is called ramp-up time. The algorithm 
> is aiming at scan resistance, so a pure index access approach will not 
> show any significant changes. Therefore, don't tell me that a 1x scale 
> 10 client by 1000 transactions pgbench run doesn't show any performance 
> boost, it cannot.

などと言っているように、これだけで実際に通常のpgbenchのパフォーマンス改
善を見るのは大変です。実際、pgbenchはindex scanが中心なのでヒット率はか
なり高く、バッファ周りのパフォーマンスを調べるベンチマークとしてはふさわ
しくありません。

# ふさわしくないのに気づくのに半年かかった私が言える言葉ではありませんが

改善を見る簡単な方法は、

・VACUUMをやりながら
・あるいは、pg_dumpや(accountsのindexを外した)pgbenchと並列で実行しなが
ら

とかがいいのではないかと思います。

同様にTom Laneの

Subject: [HACKERS] Experimental patch for inter-page delay in VACUUM
Message-ID: <5464.1067568033 ＠ sss.pgh.pa.us>

も興味深いのですが、こちらの解説は他の人に任せます。

-- 
Yutaka tanida <tanida ＠ sra.co.jp>