4/30 (土)
[MyWeb] 「PostgreSQL のトランザクション & MVCC & スナップショットの仕組み」の仕組みのページを作成
ゴールデンウィークになったので新しいページをどんどん作成していきたいと思う。 その第一弾として PostgreSQL のトランザクション & MVCC & スナップショットの仕組み を作成。
4/29 (金)
[Movie] キャプテン・アメリカ シヴィル・ウォー
チネチッタで『キャプテン・アメリカ シヴィル・ウォー』を観る。 バットマン v.s. スーパーマンの後なので、最後まで和解せずにしこりを残したままというのは新鮮だ。
4/23 (土)
4/22 (金)
[PostgreSQL] 独自のインデックス・アクセス・メソッドを作る場合の覚え書き
PostgreSQL は B-tree など何種類かのインデックスをサポートしているが、PostgreSQL 文書の 35.14. インデックス拡張機能へのインターフェイス、第55章 インデックスアクセスメソッドのインターフェイス定義を参照し独自のインデックスを作ることは可能。
ただし PostgreSQL 文書に書かれていないルール、ソースコードにもはっきり書かれていない仕様が存在する。 そのような TIPS をメモとして残しておく。
- 独自のインデックスアクセスメソッドは55.2. インデックスアクセスメソッド関数で規定されたコールバックをユーザー定義関数として定義し、それを pg_am システムカタログに登録することで行う。
- 1. は独自のエクステンションを作成して行う方がよい(35.15. 関連するオブジェクトを拡張としてパッケージ化)。
- 2. だが、インデックスアクセスメソッド定義を含むエクステンションは安全に DROP EXTENSION する方法が存在しない。
- エクステンション内で CREATE {USER, TABLE, SCHEMA, TYPE, FUNCTION} などによって作成されたオブジェクトは、DROP EXTENSION を実行した時に削除される。 これは CREATE EXTENSION 実行時にエクステンション内で作成されたオブジェクトとこのエクステンションオブジェクト(pg_extension システムカタログの1行)との依存関係が pg_depend システムカタログに登録されるからである。 DROP EXTENSION は pg_extension システムカタログから 1 オブジェクトを削除する操作なので、依存関係のあるオブジェクトは連動して削除される。 これが CREATE EXTENSION 時に作成されたオブジェクトが DROP EXTENSION 時に削除されるメカニズムである。
- しかし pg_am システムカタログへの新しいインデックスアクセスメソッドの挿入は、エクステンションオブジェクトとインデックスアクセスメソッドオブジェクトの間に依存関係を作成しない。 pg_am システムカタログ内オブジェクト→ pg_exntesion システムカタログオブジェクトの依存関係を pg_depend に登録することはできるが、実際に DROP EXTENSION を行うとエラーが発生する。 pg_depend システムカタログが pg_am に対応していないから。
- そのためインデックスアクセスメソッドオブジェクトとエクステンションオブジェクトの間に依存関係が作れぬままに DROP EXTENSION を作成すると、DROP EXTENSION 時にインデックスアクセスメソッド関数は DROP FUNCTION 相当操作を受けるのに、pg_am には削除されたインデックスアクセスメソッド関数の(pg_proc システムカタログの) OID が残ってしまい、
- CREATE INDEX CONCURRENTLY をエラーで失敗させると、作成中のリレーションの残骸が残ることがある。
- いったん作成したインデックスはテーブルの定義が変わる時に再作成(reindexing)が起こる契機がある。
- ATLER TABLE ALTER COLUMN でカラムのデータ型が大きく変わった場合、REINDEX 相当のインデックスの再作成が自動的に起きる。 ambuild コールバックが呼ばれる。
- ALTER TABLE ALTER COLUMN でカラムのデータ型が変わるが格納形式が変わらない場合、例えばカラムのデータ型を text 型⇔ varchar 型で変換した場合、インデックスは実質的に REINDEX されない。 しかしその場合でもインデックスを構成していたリレーションが複製され、インデックス・リレーションの OID がつけ換わる。 ambuild コールバックは呼ばれない。
- インデックスの参照元テーブルにあった NOT NULL 制約はインデックスには引き継がれない。 テーブルのタプルディスクリプターに attnotnull が true になっていても、それをインデックスしたインデックスタプルのタプルディスクリプターの attnotnull は false である。
IndexBuildHeapScan()はテーブル内にある heap-only tuple の TID を HOT-chain の root tuple の TID に勝手に書き換えてからコールバックに渡してくる。- VACUUM は ambulkdelete コールバックと amvacuumcleanup コールバックの 2 種類が呼ばれるが、テーブル内に削除行が多い場合 ambulkdelete は複数回呼ばれる。 逆にテーブルが heap-only tuple だけで、indexed tuple がない場合には ambulkdelete コールバックが 1 度も呼ばれないことがある。 amvacuumcleanup コールバックは必ず 1 回だけ呼ばれる。
- ambulkdelete の引数 callback で渡される関数ポインタは
bool (*callback) (ItemPointer itemptr, void *state)であり、itemptr に TID を渡すことで、その TID が削除すべきかどうか判定できる仕様になっている。
ただしマニュアルには載っていないが callback の itemptr に渡してよいのは、そのインデックスが aminsert コールバックで登録されたものだけである。 それ以外の TID を渡しても結果は保証できない。 現在の実装では heap-only tuple が削除された場合、その TID を callback に渡しても true が返ってこない。 - ANALYZE の場合も amvacuumcleanup コールバックが呼ばれるが info->analyze_only によって区別することができる。
- VACUUM の処理は 1 個のトランザクションとして処理をされる。
通常のセッション内で作成したトランザクションと同様にトランザクションID(XID)がつく。
ただしこの XID は特殊である。
- 通常のセッションは
GetSnapshotData()でスナップショットを作成するが、その中に VACUUM 処理をしているプロセスは含まれない。 そのため VACUUM 処理のトランザクションは実行中であっても in progress だと判定されない。 このため正常に MVCC 判定を受けない。 - 上記の制限から VACUUM 内では
heap_insert()、heap_udpate()、heap_delete()などの操作を実行することができない。 自分の XID をどこかに記録するような処理が問題になる。 - 結局、VACUUM の中で可能なのはべき当性のある処理だけとなる。
- 通常のセッションは
4/19 (火)
テーブル結合の右・左
SQL のテーブル結合には右(right)・左(left)という言葉がたくさん出てきてやねこしいのでまとめておく。
OUTER JOIN の右・左
LEFT OUTER JOIN とか RIGHT OUTER JOIN の右左は、SQL 文中のテーブルの並び順の右左に対応する。 実際の実行計画ではテーブルの結合順は最適化されて入れ替わるので、ここでの
Hash Join の右・左
SQL のテーブル結合(Join)は Nested Loop、Hash Join、Merge Join の 3 つの方式が一般的である。 このうち Merge Join は結合する 2 つのテーブルは対称である。 しかし Nested Loop は 2 つのテーブルを 2 重ループで回すので内周と外周があり、Hash Join もハッシュテーブルをビルド(build)するテーブルと、ハッシュテーブルを検索(probe)するテーブルがあり、非対称となる。
Hash Join の場合、build 側を左、probe 側を右と見る。 実行計画中のプランノードツリーの付き方により left-deep、right-deep、bushy、zig-zag の違いが出てくる。
PostgreSQL の lefttree、rightree
PostgreSQL は外周が lefttree、内周が rightree となる。 Hash Join の場合、内周側が build、外周側が probe となるため、SQL の世界の right/left と lefttree/rightree が逆になる。