バッファ管理。clock sweepアルゴリズム、BufferAccessStrategyData構造体

DB PostgreSQL

clock sweepアルゴリズム

clock sweepアルゴリズムは、使用頻度のもっとも低いものを選択するアルゴリズム。厳密にバッファの利用頻度を管理できないがLRUよりもオーバヘッドが少ないらしい。バッファはフレームごとに使用された回数を保持しているが、この値を参照して、どのページを置き換えるべきか判断する。

使用された回数を保持する変数は、BufferAccessStrategyDataによってセットのされ方が異なる。また、BufferAccessStrategyData自体もデフォルト（NULL）が使われるかバルクリード用のものが使われるかが実行計画などの要因によって異なるみたい。シーケンシャルスキャンのときはバルクリード用のものが使われた。

BufferAccessStrategyData構造体によるバッファのリングキュー

BufferAccessStrategyDataが使われるときは、デフォルトで最大32のバッファのフレームがここで管理される。この構造体はプロセスに固有。32のフレームがFIFOで使いまわされる。
この仕組みがあるのは、大量のブロックをディスクから読み込む必要がある場合に、1プロセスの都合ですべてのバッファキャッシュを無効にすることを避けるためだと思う。キューに入る要素の数は全フレーム数より必ず小さくなるように設定されるので、単に大量データをリードするだけではclock sweepはおこらない。

バルクリード用のBufferAccessStrategyDataがどういう条件で使用されるかは、実行計画のコードを見てからもう一度チェック。

StrategyRejectBuffer関数

BufferAccessStrategyDataが使われるときはBufferAlloc関数からこの関数が呼ばれ、ダーティなページを使用しないような処理を行う。ダーティなページをフラッシュするコストを避けるため？
更新系では、この処理が呼ばれない（たぶん）は、WAL(Write Ahead Log)のプロトコルによりどのみちダーティなページのフラッシュが必要になるため？

宿題。WALとダーティなページの関係について。