B-Treeインデックス。btbulkdelete()。削除対象のItemを特定するまで

DB PostgreSQL

前回のつづき。btbulkdelete()を呼び出す前に、テーブルから削除対象のタプルをスキャンしそのポインタを記憶しておき、後でそれを参照することで削除すべきインデックスのItemを特定していることがわかった。

  • lazy_scan_heap()
    • VACUUM対象リレーション（インデックスではなくテーブルのリレーション）の全Pageのタプルを対象とする。
    • ページ内のタプルを1件ずつ見てVACUUMしていいかどうかみる。主にHeapTupleSatisfiesVacuum()とかの処理。
    • VACUUM可能なタプルなら記録する。lazy_record_dead_tuple()の処理。（記録するのはテーブルのタプル（へのポインタ））
    • カタログを見てリレーションにインデックスがあればインデックスごとにlazy_vacuum_index()を呼ぶ。
  • lazy_vacuum_index()
    • コールバックの関数lazy_tid_reaped()のポインタをindex_bulk_delete()に渡す。lazy_tid_reaped()は、バイナリサーチで削除対象のタプルを見つける関数。btvacuumpage()で使用される。
  • btbulkdelete()
    • B-Treeインデックスの実装。
  • btvacuumscan()
    • インデックスのメタページを除く全Pageを順にbtvacuumpage()に渡す。
  • btvacuumpage()
    • LEAFページの場合は、全Itemをひとつずつコールバックの関数に渡し、削除対象かどうかチェック。削除対象ならItemのオフセット番号を配列にとる。
    • _bt_delitems()にその配列を渡しページからの削除を依頼。

所感

  • FULL VACUUM でないものは LAZY VACUUMと呼ばれるらしい。
  • テーブルのページを全件みて、そのあとでインデックスのページもインデックスごとに全件みている。データ量が多ければ多いほど大変そう。
  • バイナリサーチで比較しているのはデータの値ではなくItemPointer（ブロック番号とオフセット番号の構造体）。