PostgreSQLの内部構造

第2章ではPostgreSQLの内部構造を紐解きながら，基礎的な部分にフォーカスしていきます。

PostgreSQLの内部構造を知ることで，次章以降の事前知識にもなりますし，PostgreSQLの新機能がいかにして成長してきたかも見えてきます。

PostgreSQLのソースコードの場所

PostgreSQLのソースコードは全部で120万行以上（2018月11月27日現在）あります。これをすべて把握するのは難しいので，本章では重要なワードとその概要を押さえながら話を進めていきます。

もっと詳しく知りたいと思った人は，そのワードで公式ドキュメントを検索してください。それよりもさらに深く知りたいと思った人は，ソースコードリーディングをお勧めします。PostgreSQLのコードは，統率されたきれいなコードとなっています。C言語の初心者でも読みやすく，ミドルウェアのコードとしても学びが多いです。

プロセスの構造と役割

まずはプロセスについて説明します。

PostgreSQLは，マルチプロセスタイプのアーキテクチャです。よく比較対象に挙がるMySQLは，マルチスレッドタイプのアーキテクチャです。MySQLはコネクションが生成された場合，メインプロセスがスレッドを生成します。それに対してPostgreSQLはプロセスを生成します。

Linuxアーキテクチャに詳しい人からすると，PostgreSQLは無駄な実装に感じるかもしれません。たしかにスレッドとプロセスの生成ではスレッドのほうが軽量です。ですがRDBMSの性能はそこだけで決まるほど簡単なものではなく，たとえばロックの待ち時間に比べれば誤差と言えるでしょう。

このようにPostgreSQLはマルチプロセスですから，それぞれのプロセスを知ることは重要です。主なプロセスは表1のとおりで，それらプロセスの流れは図1のとおりです。図1に登場していない表1のプロセスは，スタートアッププロセスのように常駐しないものや，アーカイバやWALセンダのように設定した場合のみ登場するものです。

PostgreSQLは，ライタがデータファイルやインデックスファイルをディスクに更新しています。ただし，その更新は，コミットに合わせてリアルタイムで行われているわけではありません。性能向上のため，チェックポイントと呼ばれる更新タイミングが発生するまでは，更新があっても共有バッファにデータを貯めておきます。この貯められたデータをダーティページと呼びます。そしてチェックポイントのタイミングで，チェックポインタがダーティページをディスクに書き込みます。

そのため，共有バッファに更新情報を貯めている間に障害が起きると，ダーティーページを失う可能性があります。それを防ぐために，共有バッファ中のデータに対してどのような更新を行ったかの情報を保存しているのがWALです。WALはコミットのタイミングでWALライタが記録しています。クラッシュリカバリが必要になったときは，WALの中にある記録を使用してデータ消失を防ぎます。共有バッファなどのメモリについては次節で説明します。

このようにPostgreSQLは，さまざまプロセスが役割分担をしながら処理しています。