A Tour of PostgreSQL

A Tour of PostgreSQL
Masahiko Sawada
PostgreSQL Conference Japan 2020
1

© Copyright EnterpriseDB Corporation, 2020. All rights reserved.2
Agenda
• モチベーション
• OSから⾒見見たPostgreSQL
• 「データ」を中⼼心にPostgreSQL内部構造を紐解く
• PostgreSQLの構成
• SQL処理理
• テーブル／インデックス
• トランザクション
• まとめ

モチベーション
内部構造を知ることはなにに役に立つのか?
3

ユーザだけど…内部構造を知ることは必要？
Feel the breath of PostgreSQL
予想している聴講者層
• これからPostgreSQLを使いたい／勉強したい
• 実際に運用している
このような方々にも役に立つ！
• 他のRDBMSとの違いを知りたい
• PostgreSQLをいじってみたい

用語紹介と概要
データベースクラスタ
データベース
スキーマ
a.users b.users …

PostgreSQLのプロセス群
OSから見れば一つのプログラム
$ ll -h bin/postgres
-rwxr-xr-x 1 masahiko masahiko 25M Oct 28 18:10 bin/postgres
$ ps x | grep postgres
72572 - Ss 0:00.89 /usr/home/masahiko/pgsql/master/bin/postgres -D data -p 5432
72574 - Ss 0:00.39 postgres: checkpointer (postgres)
72575 - Ss 0:01.82 postgres: background writer (postgres)
72576 - Ss 0:01.95 postgres: walwriter (postgres)
72577 - Is 0:00.34 postgres: autovacuum launcher (postgres)
72578 - Ss 0:01.15 postgres: stats collector (postgres)
72579 - Is 0:00.03 postgres: logical replication launcher (postgres)
75547 - Ss 0:00.00 postgres: masahiko postgres [local] idle (postgres)

PostgreSQLのプロセス群
OSから見れば一つのプログラム
Backend
Postmaster
Backend
Backend
Checkpointer
Wal writer
Bg writer
LoggerArchiver
Autovacuum

launcher/worker
Wal

sender/receiver
Stats collector
Logical repl.

launcher/worker
Clients

PostgreSQLのディレクトリ構造
データベースクラスタの実体は一つのディレクトリ
$ ls ${PGDATA}
PG_VERSION pg_dynshmem pg_notify pg_stat_tmp pg_xact
base pg_hba.conf pg_replslot pg_subtrans postgresql.auto.conf
global pg_ident.conf pg_serial pg_tblspc postgresql.conf
pg_commit_ts pg_logical pg_snapshots pg_twophase postmaster.opts
pg_multixact pg_stat pg_wal postmaster.pid

少しずつ見えてきた！
• クライアントが一つのデータベースに接続すると、一つのプロセスがSQLを処理する
• PostgreSQLは様々な役割を持ったプロセスの集合
• データベースクラスタはOSからみると1つのディレクトリ

「データ」を中心に
PostgreSQL内部を
見てみる
11

本発表でのアプローチ
• 1つのSQLを例に、PostgreSQLがどのよ
うに処理し、データを取得するのかを順番
に解説
• 必要に応じて少し脱線し、関連する機能や
仕組みを紹介
• 最終的には大まかな全体像が掴める
• PostgreSQL13を元に解説します
https://jp.depositphotos.com/v/3oi2kp.html

SQLを理解する
SELECT * FROM users WHERE id = 100;
• パーサが受け取ったSQLの構文を解析する
• SELECT文？UPDATE文？文法は正しい？
• ERROR : syntax error at or near xxxx"
• 文法的に正しければOK
• テーブルや列が本当にあるかどうかは気にしない
Parser
SelectStmt

• targetList

• fromClause 
• whereClause

A_STAR
=
100id
users

パースツリーを解析する
• アナライザがテーブルや列の存在チェックをする
• ERROR: relation "badtable" does not exist at character 15
• システムカタログを使う
• （リライタ（Rewriter）がクエリの書き換えを行う）
Parser
Analyzer

システムカタログ
PostgreSQLのメタデータが詰まった内部テーブル
• 実体は通常のテーブルと同じ
• PostgreSQL13には62個ある
• テーブル、テーブルにある列、インデックス、データ型、演算子、トリガー、関数、ユーザ、型変
換など、内部的な情報はすべてシステムカタログにある
• テーブルとしてpg_catalogスキーマに存在するので、SQLでアクセスできる
• 例）テーブルを検索する時：
• SELECT relname FROM pg_class WHERE relname = user and relkind = r ;
Parser
Analyzer

例）テーブルを作った時
CREATE TABLE users (id INT PRIMARY KEY, name TEXT);
• テーブル、インデックス(主キー) → pg_class
• インデックス(主キー) → pg_index
• id列、name列 → pg_attribute
• 主キー制約 → pg_constraint
• 依存関係（テーブルを削除したら主キーも削除する） → pg_depend
Parser
Analyzer

[少し脱線] 共有する／しないシステムカタログ
• データベース、ユーザなどはデータベースクラスタ全体で共有するので対応するカタログ
（pg_database, pg_authidなど）は共有するシステムカタログ(pg_class.isshared = t )
• その他の定義情報（テーブル、トリガなど）は、データベース毎に存在する
Parser
Analyzer

どのようにデータを取得するか？
• テーブルの状態、検索条件によって最適なアクセス方法は異なる
• テーブルにはたった10行しか入っていないかもしれない
• 1億行の内から一つの行を取得するかもしれない
• プランナが最適（だと思われれる）な実行プランを計画する
• 実行プラン：どのように目的のデータを取得するのかをまとめた計画
Parser
Analyzer
Planner

代表的なアクセス方法
• Seq Scan
• テーブルの（物理的な）先頭から順番にスキャンする
• テーブル内の多くの割合のデータを取得する時に高速
• Index Scan
• インデックスをスキャンしてから、テーブルをスキャンする
• テーブル内の一部のデータを取得する時に高速
Parser
Analyzer
Planner

PostgreSQLがサポートする実行ノード
Aggregate ForeignScan HashJoin MergeAppend Result SubQueryScan WorkTableScan
BitmapAnd FunctionScan IncrementalSort MergeJoin SampleScan TableFuncScan
BitmapHeapSc
an
Gather IndexOnlyScan NamedTupleSt
oreScan
SeqScan TidScan
BitmapIndexSc
an
GatherMerge Limit NestLoop SetOp Unique
BitmapOr Group LockRows ProjectSet Sort ValueScan
CteScan Hash Material RecursiveUnion SubPlan WindowAgg
Parser
Analyzer
Planner

どうやってプランを決めるのか？
まずは選択度
• テーブルの統計情報を利用して最適なアクセス方法を決める
• 列の固有値 : (例）一意の列の固有値は-1。都道府県を格納する列の固有値は＝47
• 列の最頻値 : 最も多いデータとその割合のペアのリスト
• most_common_vals : {user0,user1,user2,user3,user4,user5,user6,user7,user8,user9}
• most_common_freqs : {0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1,0.1}
• 列のヒストグラム : 度数を均一にしたときのBinの境界値
• histogram_bounds : {1,100,200,300,400,500,600,700,800,900,1000}
• pg_statsビュー
• 統計情報はANALYZEで更新
Parser
Analyzer
Planner

行数の見積もり
選択度（Selectivity）の決定
等価条件（WHERE id = 100）の場合
• 列が主キー（固有値が-1）なら簡単
• 必ず0行か1行
• 最頻値から探す
• あればその割合が選択度
• なければ「それ以外の割合」から選択度を求める
Parser
Analyzer
Planner
範囲条件（WHERE id < 100）の場合
• ヒストグラムから100を含むBinの位置を求める
• 「そのBin」＋「それより前のBin」が占める割合を選択
度とする
80 120 200 500

コストの見積もり
（推定）取得行数から処理コストを計算する
• Seq Scanの場合
• 取得行数によらず一定
• 必要なデータ＝テーブルサイズ
• Index Scanの場合
• 取得行数によってコストが異なる
• 必要なデータ＝インデックス内を探す時に必要なデータ＋ 
テーブル内の検索対象が入っているデータ
Parser
Analyzer
Planner
Index Scan
Seq Scan
Cost
# of tuples

[少し脱線] 結合の場合はどうなる？
• プランはボトムアップにプラン候補を集め
ながら決めていく
• テーブルのスキャン方法→結合方法
→…
Parser
Analyzer
Planner
https://www.pgcon.org/2016/schedule/attachments/433_PGCON2016_beyond_explain.pdf

EXPLAIN
実行プランの確認
cost : プランナが見積もったコスト
rows : プランナが見積もった取得行数
width : プランナが見積もった行のサイズ
=# EXPLAIN SELECT * FROM users WHERE id = 100;
QUERY PLAN
-------------------------------------------------------------------------
Index Scan using users_pkey on users (cost=0.28..8.29 rows=1 width=10)
Index Cond: (id = 100)
(2 rows)
Parser
Analyzer
Planner

計画したプランを実行する
• エグゼキュータが受け取ったプランを実行する
• PostgreSQLのエグゼキュータはPull方式
• 再帰的にノードを実行していく
• 全ての実行ノードは1行返す
• EXPLAIN ANALYZEでプランと一緒に実行時間を確認できる
Parser
Analyzer
Planner
Executor

プランはどのように実行されるのか？
QUERY PLAN
-------------------------------------------------------------------------
Index Scan using users_pkey on users (actual time=0.020..0.021 rows=1 loops=1)
(2 rows)
Executor
Parser
Analyzer
Planner
Executor

1⾏行行ちょうだい
QUERY PLAN
-------------------------------------------------------------------------
(2 rows)
Parser
Analyzer
Planner
Executor

QUERY PLAN
-------------------------------------------------------------------------
(2 rows)
Parser
Analyzer
Planner
Executor

QUERY PLAN
-------------------------------------------------------------------------
(2 rows)
どうぞ
最初の⾏行行を
取得するまでに
かかった時間(ms)
Parser
Analyzer
Planner
Executor

QUERY PLAN
-------------------------------------------------------------------------
(2 rows)
Parser
Analyzer
Planner
Executor

QUERY PLAN
-------------------------------------------------------------------------
(2 rows)
もうないよ
処理理が完了了
した時間
Parser
Analyzer
Planner
Executor

[少し脱線] ソートの場合はどうなる？
SELECT * FROM users WHERE id < 100 ORDER BY id;
QUERY PLAN
---------------------------------------------------------------------------------------
Sort (actual time=1.646..1.656 rows=99 loops=1)
Sort Key: name
Sort Method: quicksort Memory: 30kB
-> Index Scan using users_pkey on users (actual time=0.025..0.067 rows=99 loops=1)
Index Cond: (id < 100)
ソートした結果を返したい
Parser
Analyzer
Planner
Executor

QUERY PLAN
---------------------------------------------------------------------------------------
Sort Key: name
1⾏行行取得！
Parser
Analyzer
Planner
Executor

QUERY PLAN
---------------------------------------------------------------------------------------
Sort Key: name
1⾏行行取得！！
Parser
Analyzer
Planner
Executor

QUERY PLAN
---------------------------------------------------------------------------------------
Sort Key: name
1⾏行行取得！！！
Parser
Analyzer
Planner
Executor

QUERY PLAN
---------------------------------------------------------------------------------------
Sort Key: name
1⾏行行取得！！！！
Parser
Analyzer
Planner
Executor

QUERY PLAN
---------------------------------------------------------------------------------------
Sort Key: name
1⾏行行取得！！！！！× 99
Parser
Analyzer
Planner
Executor

QUERY PLAN
---------------------------------------------------------------------------------------
Sort Key: name
全部そろったからソートするよ
Parser
Analyzer
Planner
Executor

QUERY PLAN
---------------------------------------------------------------------------------------
Sort Key: name
やっと1⾏行行返せる
Parser
Analyzer
Planner
Executor

ユーザ(name = user_100 )の給料を検索する
=# EXPLAIN SELECT * FROM users, salary WHERE
users.id = salary.id and users.name = ‘user_100';
QUERY PLAN
--------------------------------------------------------------------------------
Nested Loop (cost=0.29..26.80 rows=1 width=18)
-> Seq Scan on users (cost=0.00..18.50 rows=1 width=10)
Filter: (name = 'user_100'::text)
-> Index Scan using salary_pkey on salary (cost=0.29..8.30 rows=1 width=8)
Index Cond: (id = users.id)
(5 rows)
users salary

QUERY PLAN
--------------------------------------------------------------------------------
(5 rows)
まずは内部表（駆動表）
から1⾏行行とるよ
Parser
Analyzer
Planner
Executor

QUERY PLAN
--------------------------------------------------------------------------------
(5 rows)
まずは内部表（駆動表）
Parser
Analyzer
Planner
Executor

QUERY PLAN
--------------------------------------------------------------------------------
(5 rows)
先程取った⾏行行のID列列の
値を使って次は内部表
Parser
Analyzer
Planner
Executor

QUERY PLAN
--------------------------------------------------------------------------------
(5 rows)
1⾏行行結合できたので、
エグゼキュータに返すよ
Parser
Analyzer
Planner
Executor

ここまでのまとめ
パーサがSQLを構文解析し、
アナライザがシステムカタログを使ってテーブルや列の有無を確認し、
プランナが統計情報を使って実行プランを計画し、
エグゼキュータが実行プランを実行する。
Parser
Analyzer
Planner
Executor

実際にデータを読む
PostgreSQLはデータをどのように管理するのか？
• テーブルやインデックスの実体は1つのファイル
• 8kB（ブロック）単位で読み書きする
• 共有バッファに読んだデータをキャッシュする
• OSのファイルキャッシュも利用する
• shared_buffersで調整
• 満杯になったら入れ替える（Clock Sweep）
• CheckpointerやBgwriterが変更したデータをディス
クに書き込む
File Cache

(OS)
Disk
Executor

(PostgreSQL)
SharedBuffer

(PostgreSQL)

PostgreSQLのメモリ
共有するメモリとしないメモリ
• プロセス間で共有するデータは共有メモリに確保
• 共有バッファ、ロック、管理情報など
• 例）shared_buffersは共有メモリとして一つ確保
• プロセス内だけで使うメモリはプロセス毎に確保
• プランニング時に使うメモリ、ソート等のSQL実行時に使うメモリ、システムカタログの
キャッシュなど
• 例）work_memはプロセス毎に確保する

ここまでのまとめ
• PostgreSQLのプロセス構造が分かってきた
• postmasterやbackendプロセス
• SQLがどのように処理されるのかが分かってきた
• パーサ、アナライザ、プランナ、エグゼキュータ
• EXPLAINの読み方、どのように実行されるのかも分かってきた
• PostgreSQLはデータを共有バッファ、OSキャッシュ、ディスクに持っている

PostgreSQLを完全に理解した？
ワタシポストグレスチョットワカル
• これでは「SQLでアクセスできるデータストア」の構造を理解しただけ
• RDBMSの機能の一部分にすぎない
• 実際には複数クライアントが同時にアクセスするし、途中でクラッシュするかもしれない
• データの不整合が起きない
• データが失われない

トランザクション
52
BEGIN;

SELECT …;

INSERT …;

SELECT …;

COMMIT;

SELECTとUPDATEが同時に起きたら？
• UPDATE途中のデータを見たくない
• 1回目のSELECTと2回目でSELECTで同じ結果が見たい
• ACIDのI (Isolation)
• UPDATE中はSELECTできない、というのは性能的にNG
• PostgreSQLは変更前、変更後の両方を持つことで実現している
• マルチバージョンを使った同時実行制御（MVCC）

MVCC (Multi-Version Concurrency Control)
• 1つのデータに対し複数のバージョンを持てば、一方が変更している間にもう一方が読むことがで
きる
• PostgreSQLではUPDATEを「DELETE＋INSERT」で実現
• UPDATEでもテーブルの物理的なサイズは大きくなっていく（テーブルの肥大化）
• 追記型アーキテクチャ
• ROLLBACKしたデータ（誰からも参照されないデータ）もテーブルに残る
• うまくフィルタリングしながらデータを読む

追記型とVacuum
• Vacuumで不要になった領域を回収し再利用できるようにする
• 物理的なサイズは小さくならない
Appel
Ball
Cat
Appel
Ball
Cat
Apple
Ball
Cat
Apple
Dog
Ball
Cat
Apple
UPDATE VACUUM INSERT

Vacuumのせいで遅い？
Q. Vacuum中は読み書きできる？
A. Yes
Q. Vacuumは手動、もしくはcronとかで実行する必要がある？
A. No、自動Vacuum（とHOT）があるので基本的には放っておいて大丈夫です。
Q. ゴミを確認するためにテーブルをすべてスキャンする？
A. No、ゴミがないと分かっている箇所はスキップします。

自動VacuumはどうやってVacuumするテーブルを見つける？
• 稼働統計情報を使ってVacuumするべきかどうかを判断する
• pg_stat_all_tables/indexes/functionsビュー
• テーブル内の生きているタプル数、死んでいる（Vacuumできる）タプル数、最後に
Vacuumされた時間、Vacuumされた回数など
• テーブルがSeqScanされた回数、IndexScanされた回数など

[少し脱線] UNDOログ
OracleやMySQLとの違い
• OracleやMySQLもMVCCを使っているが古いデータをUNDOログに持つ
• 要らなくなったらUNDOログをまとめて削除すれば良い
• テーブル内にはゴミは溜まらない
• テーブルをチェックする必要はない
• テーブルの肥大化は起きにくい方式
• UNDOログの方が優れている、とも言えない
• 例）ROLLBACKに時間がかかる（ゴミだと思っていたけどやっぱり違った）

トランザクションのステータス
COMMIT、ABORTはどうやって判断する？
• ACIDのA（Atomicity）
• PostgreSQLは各トランザクションにID（単調増加の非負整数）を割り当てる（XID）
• コミットログと呼ばれるファイルに、各トランザクションがCommit/Abortした情報を格納する（2bits／txn)
• たくさんテーブルを更新してもたった2bitの更新でCommit/Abortを記録する
• 各タプルには「INSERTされたトランザクションのXID（=xmin）」と「DELETEされたトランザクションの
XID（=xmax）」の両方を持つ
• タプルから取得したXIDからステータスを確認して、「COMMITされたINSERT」なのか「ABORTされた
INSERT」なのかを確認する
90 Apple120
Commit log
00100 … 0110

タプルの可視性
ゴミも混ざっているテーブル内のタプルをどのように正しく読むか？
• モチベーションの例）トランザクション内では、一度読んだデータをもう一度読んでも同じデータが返ってきて
ほしい！
• REPEATABLE READに相当する
• これまで紹介した仕組みを組み合わせる（マルチバージョン、XID、コミットログ）
• 基本的な考え方
• 自分のXIDより小さいXIDで追加されたデータは読める（過去に追加された）
• 自分のXIDより小さいXIDで削除されたデータは読めない（過去に削除された）
• ただし例外も・・・
• 現在進行中のトランザクションによって行われた（たとえXIDが小さくても）変更は見てはいけない

データベースのスナップショットを見る
データベースある時点を切り取ったようなデータ
100 Apple
XID = 100: INSERT ‘Apple’;
xmin

(insert)
xmax

(delete)

100 Apple
100 Ball

INSERT ‘Ball’;
xmin

(insert)
xmax

(delete)

100 200 Apple
100 Ball
200 Cat

INSERT ‘Ball’;

XID = 200: UPDATE ‘Apple’ -> ‘Cat’;
xmin

(insert)
xmax

(delete)

100 200 Apple
100 Ball
200 Cat

INSERT ‘Ball’;

xmin

(insert)
xmax

(delete)
XID = 150

100 200 Apple
100 Ball
200 Cat

INSERT ‘Ball’;

xmin

(insert)
xmax

(delete)
XID = 150 xmin = 100 → 過去にINSERTされた
xmax = 200 → 未来でDELETEされる 
見える！！

100 200 Apple
100 Ball
200 Cat

INSERT ‘Ball’;

xmin

(insert)
xmax

(delete)
XID = 150 xmin = 100 → 過去にINSERTされた
まだ誰からも削除されていない 
見える！！

100 200 Apple
100 Ball
200 Cat

INSERT ‘Ball’;

xmin

(insert)
xmax

(delete)
XID = 150 xmin = 200 → 未来にINSERTされる
まだ誰からも削除されていない 
見えない！！

すべてはログに書いてある
• コミット済みのデータを失わない！
• ACIDのAとD（Durability）
• WAL (Write Ahead Logging)
• データ（テーブルやインデックス）の変更をディスクに反映する前に、必ず対応するロ
グをディスクに反映する
• COMMIT後にクラッシュしてもログを再生すれば元通り（ロールフォワード）

Shared Buffer Disk WAL(Disk)

Disk
Apple
INSERT ‘Apple’;

WAL(Disk)
INS: Apple
Shared Buffer

Disk
Apple
Ball
INSERT ‘Apple’; 
INSERT ‘Ball’;

WAL(Disk)
INS: Apple
INS: Ball
Shared Buffer

Disk
Apple
Ball
INSERT ‘Ball’;

WAL(Disk)
INS: Apple
INS: Ball
Apple
Ball
Sync
Shared Buffer

Disk WAL(Disk)
Apple
Ball
Alice
INSERT ‘Ball’;

UPDATE ‘Apple’ -> ‘Alice’;

INS: Apple
INS: Ball
UPD: 1 -> ‘Alice’
Apple
Ball
Shared Buffer

Disk WAL(Disk)
Apple
Ball
Alice
Cat
INSERT ‘Ball’;


INSERT ‘Cat’;

INS: ‘Apple’ at 1
INS: ‘Ball’ at 2
UPD: 1 -> ‘Alice’ at 3
INS: ‘Cat’ at 4
Apple
Ball
Shared Buffer

Disk WAL(Disk)
Apple
Ball
Alice
Cat
INSERT ‘Ball’;


INSERT ‘Cat’;

INS: ‘Cat’ at 4
Apple
Ball
Shared Buffer

Disk WAL(Disk)
INSERT ‘Ball’;


INSERT ‘Cat’;

INS: ‘Cat’ at 4
Apple
Ball
Shared Buffer

Disk WAL(Disk)
INSERT ‘Ball’;


INSERT ‘Cat’;

INS: ‘Cat’ at 4
Apple
Ball
Apple
Ball
Alice
Shared Buffer

Disk WAL(Disk)
INSERT ‘Ball’;


INSERT ‘Cat’;

INS: ‘Cat’ at 4
Recovery !!

(Roll Forward)
Apple
Ball
Alice
Cat
Apple
Ball
Shared Buffer

Disk WAL(Disk)
INSERT ‘Ball’;


INSERT ‘Cat’;

INS: ‘Cat’ at 4
Recovery !!

(Roll Forward)
Apple
Ball
Alice
Cat
Apple
Ball
Alice
Cat
Sync
Shared Buffer

すべてはログに書いてある
• クラッシュしてもCOMMIT済みのデータは失われない！
• WALはSequential Writeになる
• WALはpg_wal配下に格納される。絶対消さないで！
$ ls ${PGDATA}/pg_wal/
00000001000000000000002B 000000010000000000000032 archive_status
00000001000000000000002C 000000010000000000000033
00000001000000000000002D 000000010000000000000034
00000001000000000000002E 000000010000000000000035
00000001000000000000002F 000000010000000000000036
000000010000000000000030 000000010000000000000037
000000010000000000000031 000000010000000000000038

今回触れられなかった部分
• ロック
• トランザクション分離レベル
• 補助プロセス群（Wal writer、Checkpointerなど）
• その他高度な機能（レプリケーション、パラレルクエリ、パーティショニング、など）
• きっと次の講演で聞けるはず！

まとめ
Feel the breath of PostgreSQL
• PostgreSQLがどのようにSQLを処理し、データを取得しているのか
• どのように同時実行制御しているのか
• COMMIT済みのデータが決して失われない仕組み
• PostgreSQLはもちろんRDBMSの勉強としても役立つ
• この後の講演の理解度もぜんぜん違う（はず）！

Thank you
Masahiko Sawada
masahiko.sawada@enterprisedb.com

A Tour of PostgreSQL

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a A Tour of PostgreSQL

Similar a A Tour of PostgreSQL (20)

Más de EDB

Más de EDB (20)

Último

Último (8)

A Tour of PostgreSQL