PostgreSQLが書き込みロックなしで同時にインデックスを構築する方法を理解しようとしています。
テーブルデータに継続的に書き込まれている間、これを行うためにPostgreSQLによって実行される手順を誰かが説明できますか?
PostgreSQLが書き込みロックなしで同時にインデックスを構築する方法を理解しようとしています。
テーブルデータに継続的に書き込まれている間、これを行うためにPostgreSQLによって実行される手順を誰かが説明できますか?
関連する詳細は、ソース コードのコメントにあります。2607 行付近のコメントをvalidate_index
参照src/backend/catalog/index.c
してください。
最初に index_create() を介してインデックスのカタログ エントリを挿入し、indisready ではなく、indisvalid ではないことをマークすることにより、同時インデックス構築を行います。次に、トランザクションをコミットして新しいトランザクションを開始し、テーブルを変更していた可能性のあるすべてのトランザクションが終了するのを待ちます。
....そしてたくさん、もっとたくさん。基本的に「複雑」です。説明しようと思いますが、コードを詳しく読んでおらず、コードベースのこの部分も知らないので、正しい説明はコメントとソース コードだけです。
私の理解では、テーブルの状態の MVCC スナップショットに基づいて初期ビルドを行い、完了時にコミットします。次に、すべてのトランザクションが (壊れた) インデックスを確認できるようになるまで待機します。この時点で、テーブル内の内容が変更されたときにすべてのトランザクションが更新されます。次に、インデックスを構築したときに表示されていたものと現在表示されているものを比較し、スナップショット間の違いを反映するようにインデックスを更新します。次に、インデックスが無効な状態にある間にインデックスを参照できるトランザクションがないことを確認するために待機し、インデックスを有効としてマークし、再度コミットします。
プロセス全体は、MVCC スナップショットと可視性に大きく依存しています。また、I/O、CPU、および RAM の点で、通常のインデックス構築よりもかなりコストがかかります。
validate_index
全体のプロセスに関する詳細を含むDefineIndex
src/backend/commands/indexcmds.cで呼び出されます。