PostgreSQL 15の新機能を徹底解説

© 2022, Amazon Web Services, Inc. or its affiliates.
PostgreSQL開発者が
PostgreSQL15の新機能を
徹底解説
澤田雅彦 (Sawada Masahiko)
Senior Software Development Engineer
AWS

PostgreSQL 15 が10/15にリリース！
189個
の新機能
(229)
2472個
のコミット
(2702)
412人
の開発者
(415)
34人
の日本人開発者
(36)

PostgreSQL 10がEOL
3

Index
• SQL
• Logical Replicationの改善
• WAL、リカバリ、バックアップ
• 性能
• モニタリング
4

本発表について
• 本発表に掲載している検証結果は以下の環境で取得したものです
• 環境や条件などによっては、異なる結果となる可能性があります
• AWS EC2 m6ld.metal, RHEL8.6, 128 vCPUs, 512GB RAM, SSD
5

MERGE
• ソーステーブルとターゲットテーブルの結合条件を元にテーブルに対して、
INSERT/UPDATE/DELETEを実行できる
• SQL標準
6
user_id last_login
100 2022/9/26 11:00
200 2022/7/13 13:00
user_id login_at
100 2022/10/30 11:50
200 2022/10/14 10:40
300 2022/10/24 15:00
user_id last_login
100 2022/10/30 11:50
200 2022/10/14 10:40
300 2022/10/24 15:00
login_historyテーブル (ソース) user_historyテーブル (ターゲット) user_historテーブル (MERGE後)

MERGE
7
user_id last_login
100 2022/9/26 11:00
200 2022/7/13 13:00
user_id login_at
100 2022/10/30 11:50
200 2022/10/14 10:40
300 2022/10/24 15:00
user_id last_login
100 2022/10/30 11:50
200 2022/10/14 10:40
300 2022/10/24 15:00
MERGE INTO user_history u USING login_history l
ON (u.user_id = l.user_id)
WHEN MATCHED THEN
UPDATE SET last_login = l.login_at
WHEN NOT MATCHED THEN
INSERT VALUES (l.user_id, l.login_at);

MERGE
8
user_id last_login
100 2022/9/26 11:00
200 2022/7/13 13:00
user_id login_at
100 2022/10/30 11:50
200 2022/10/14 10:40
300 2022/10/24 15:00
user_id last_login
100 2022/10/30 11:50
200 2022/10/14 10:40
300 2022/10/24 15:00
WHEN MATCHED THEN
user_idが一致する行があった場合の動作

MERGE
9
user_id last_login
100 2022/9/26 11:00
200 2022/7/13 13:00
user_id login_at
100 2022/10/30 11:50
200 2022/10/14 10:40
300 2022/10/24 15:00
user_id last_login
100 2022/10/30 11:50
200 2022/10/14 10:40
300 2022/10/24 15:00
WHEN MATCHED THEN
user_idが一致する行がなかった場合の動作

MERGEで指定できるアクション
• INSERT
• UPDATE
• DELETE
• DO NOTHING
10

MERGEの注意点
• 各行は0 or 1行と結合できる場合のみ動く
• 到達しない条件がある場合はシンタックスエラー
(ERROR: unreachable WHEN clause
specified after unconditional WHEN
clause)
11
11
user_id last_login
100 2022/9/26 11:00
200 2022/7/13 13:00
user_id login_at
100 2022/10/30 11:50
200 2022/10/14 10:40
300 2022/10/24 15:00
100 2022/10/31 12:00
user_id last_login
100 2022/10/30 11:50
200 2022/10/14 10:40
300 2022/10/24 15:00
WHEN MATCHED THEN
WHEN MATCHED AND user_id = 100 THEN
DO NOTHING;

MERGEとINSERT … ON CONFLICT
• どちらも「格納されている行に応じて動作を切り替える事」が可能
• MERGEはUPDATEだけでなく、INSERT/DELETEを指定することも可能
• MERGEとINSERT … ON CONFLICTは単純には置き換えられない
• 同時実行性
• 性能
• トリガ
12

MERGEの性能
13
0
2000
4000
6000
8000
10000
12000
INSERT … ON CONFLICT MERGE
300万件UPDATEした場合(ms)
0
1000
2000
3000
4000
5000
6000
7000
INSERT … ON CONFLICT MERGE
300万件INSERTした場合(ms)
• 「INSERTしたケース」と「コンフリクトしたからUPDATEしたケース」で
INSERT … ON CONFLICTとMERGEの性能を比較

Logical Replicationとは
• データベースの一部を他のデータベースに複製する機能
• WALをデコードした内容を送信する
• Publisher（送信側）とSubscriber（受信側）
• PUBLICATIONとSUBSCRIPTION
• CDC、BI、メジャーバージョンアップ、マルチマスター
14

CREATE SUBSCRIPTION … WITH (two_phase = on)
• 2相コミットの情報が複製可能になった
• Off(デフォルト）だとPublisherで2相コミットしても、通常のトランザクショ
ンとして複製される
• 未コミット/未ロールバックのトランザクションがSubscriberにも残るように
なるので注意
15

行フィルターと列フィルター
CREATE PUBLICATION pub1 FOR TABLE tbl (id, user), tbl2;
CREATE PUBLICATION pub2 FOR TABLE tbl WHERE (id % 2 = 0);
CREATE PUBLICATION pub3 FOR TABLE tbl (id, user) WHERE (id % 2 = 0);
16
• 送信側でデータをフィルタリング
• 同時に指定することも可能

スキーマ単位で送信テーブルを指定
• これまではテーブルを複数指定するか、ALL TABLESで全テーブル指定のみ
• 指定したスキーマ内の全テーブルを指定可能になった
• スキーマに新たに追加されるテーブルも対象
17
CREATE PUBLICATION pub1 FOR TABLE tbl;
CREATE PUBLICATION pub2 FOR ALL TABLES;
CREATE PUBLICATION pub3 FOR TABLES IN SCHEMA s1;

ALTER SUBSCRIPTION … SKIP
• より便利になった衝突解決のための新しい手段
• 衝突は様々な場面で起こり得る
• 例）Subscriberで同時にINSERTして主キー違反
• 衝突が解決するまでLogical Replicationはリトライし続ける
• 衝突を解決するには・・・
• 衝突している行を削除/更新
• Logical Replicationの開始地点を進める
18

ERROR: duplicate key value violates unique constraint "tbl_pkey"
DETAIL: Key (c)=(1) already exists.
CONTEXT: processing remote data for replication origin "pg_16389" during
"INSERT" for replication target relation "public.tbl" in transaction 740
finished at 0/1554338
サーバログ
• エラーになった操作、テーブル名、トランザクションID、トランザクション
が完了するLSNがサーバログに書かれる
• この情報を元に特定のトランザクションをスキップする

ERROR: duplicate key value violates unique constraint "tbl_pkey"
DETAIL: Key (c)=(1) already exists.
CONTEXT: processing remote data for replication origin "pg_16389" during "INSERT"
for replication target relation "public.tbl" in transaction 740 finished at
0/1554338
20
=# ALTER SUBSCRIPTION sub SKIP (lsn = ‘0/1554338’);
サーバログ
SQL
LOG: logical replication starts skipping transaction at LSN 0/1554338
LOG: logical replication completed skipping transaction at LSN 0/1554338
サーバログ

pg_basebackupの強化
• データベースクラスタ全体の物理バックアップを取得するツール
• サーバ側での圧縮（gzip, lz4, zstd）、クライアント側（gzip, lz4, zstd）での
圧縮をサポート
例）--compress=server-zstd, --compress=client-lz4,
--compress=server-zstd:level=9,workers=4
• バックアップの出力先（サーバ or クライアント）を指定可能に
例）--target=server:/some/path, --target=client
21

バックアップサイズとバックアップ取得時間を比較
• バックアップサイズは、圧縮方法、圧縮レベルを変えて検証
• バックアップ時間は、圧縮方法、並列数を変えて検証
• 同一サーバ上からpg_basebackupを実行したためサーバ側圧縮のみ実施
22
0
10
20
30
40
50
60
70
80
90
100
none server:zstd server:lz4 server:gzip
バックアップ時間(s)
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
none server:zstd server:lz4 server:gzip
バックアップサイズ(MB)

contrib/basebackup_to_shell
• 新しいバックアップ先としてshellを指定できるようになる
例) --target=shell:
• shared_preload_libraries = ‘basebackup_to_shell’
• basebackup_to_shell.command = ‘backup.sh %f %d’
23

[非互換] 排他バックアップが廃止
• バックアップには排他モード・非排他モードがあった
• SELECT pg_start_backup(‘label’, exclusive_backup => ‘true’);
• 排他モードでバックアップ取得中にサーバが再起動すると起動不可になる可
能性がある
• 排他モードは廃止
• pg_start_backup()とpg_stop_backup()は、pg_backup_start()と
pg_backup_stop()に関数名が変更
• 独自バックアップスクリプトで排他モードを使っている場合は、非排他モー
ドに移行する、もしくはpg_basebackupを利用する
24

archive_library
• WALアーカイブにライブラリを指定可能になった
• これまではarchive_commandにシェルコマンドを指定
• archiveプロセスが状態を持ちながら動作可能
• シェルコマンド起動(system()関数)のオーバーヘッドも省ける
• リファレンス実装としてcontrib/basic_archiveが追加
(test ! -f /path/to/dest && cp /path/to/src /path/to/des)
25

wal_compression = [off, on, pglz, lz4, zstd]
• WALの中のFull Page Imageを圧縮する
• lz4とzstdが新しく追加
• デフォルトはoff
26
0
200
400
600
800
1000
1200
1400
1600
off pglz lz4 zstd
WALサイズ
（3GBテーブルを全ページアップデート、FPIの割合約70%）

wal_compression = [off, on, pglz, lz4, zstd]
27
0
20000
40000
60000
80000
100000
120000
0 100 200 300 400 500 600
TPS (pgbench -T 300 -M prepared, sf:300)
off pglz lz4 zstd

contrib/pg_walinspect
• pg_waldumpコマンド相当の情報にSQLでアクセスできる
28
=# select * from pg_get_wal_record_info('1/A4619C00');
-[ RECORD 1 ]----+--------------------------------------------------------------------------------------
-------------------------------------
start_lsn | 1/A4619C10
end_lsn | 1/A4619E38
prev_lsn | 1/A4619BD0
xid | 774
resource_manager | Heap
record_type | LOCK
record_length | 545
main_data_length | 8
fpi_length | 484
description | off 46: xid 774: flags 0x01 LOCK_ONLY EXCL_LOCK
block_ref | blkref #0: rel 1663/5/16462 fork main blk 114 (FPW); hole: offset: 268, length: 116,
compression saved: 7592, method: zstd

30
=# select (sum(fpi_size) / sum(combined_size)) as fpi_ratio
from pg_get_wal_stats('1/A45F7758', '1/B0115CB0’);
fpi_ratio
------------------------
0.69724450466641785596
(1 row)

log_destination = jsonlog
• json形式でサーバログが出力可能になった
• logging_collector = onにする必要がある
• .jsonファイルにログが書かれる
31
{"timestamp":"2022-11-08 10:13:41.624
","pid":2934287,"session_id":"6369ad45.2cc60f","line_num":6,"session_start":"2022-11-08 10:13:41
JST","txid":0,"error_severity":"LOG","message":"database system is ready to accept
","backend_type":"postmaster","query_id":0}
{"timestamp":"2022-11-08
10:14:09.001","user":"masahiko","dbname":"postgres","pid":2934383,"remote_host":"[local]","session_id":"6369ad5e.2cc6
6f","line_num":1,"ps":"SELECT","session_start":"2022-11-08 10:14:06
","vxid":"3/2","txid":0,"error_severity":"ERROR","state_code":"42703","message":"column "a" does not
","statement":"select a;","cursor_position":8,"application_name":"psql","backend_type":"client backend","query_id":0}

log_destination = jsonlog
32

稼働統計情報が共有メモリベースに変更
• サーバの稼働統計情報（pg_stat_xxxで見れる情報）≠オプティマイザの統計
情報
• これまでは専用プロセス（stats collector）が集めていた
• 各プロセスはUDPでstats collectorに統計情報を送信
• 統計情報はファイルで共有
• これからは共有メモリ上で管理。stats collectorプロセスは廃止。
• サーバクラッシュ後に統計情報がリセットされる挙動はこれまでと同じ
33

単一列のソート性能が改善
• 単一列のソート時に扱うデータ量を削減することで、ソート性能が改善
• EXISTSやNOT EXISTSの時によく利用される
• 約700MBのテーブルでv14とv15の性能を比較
34
0
0.5
1
1.5
2
2.5
3
v14 v15
実行時間(ms)

その他の性能向上
• Parallel SELECT DISTINCT
• postgres_fdwがparallel commitをサポート
35

最後に
• PG15では、MERGE、ロジカルレプリケーションの強化、pg_basebackupの強
化を含む約200個の新しい改善が導入された
• PostgreSQL 10は昨日(11/10)にリリースされた10.23でEOL
• PostgreSQL 15.1も同時にリリースされた
• これバグかな？と思ったら
• もっと知りたい！
36

参考資料
• PostgreSQL 15.0 Documentation
(https://www.postgresql.org/docs/15/index.html)
• PostgreSQL 15 Release Note
(https://www.postgresql.org/docs/15/release-15.html)
• 篠田の虎の巻「PostgreSQL 15 Beta 1 新機能検証結果」
(https://h50146.www5.hpe.com/products/software/oe/linux/mainstream/support/lcc/pdf/PostgreSQL_15_Beta_1_New_Features_ja_2022052
4-1.pdf)
• PostgreSQL 15検証レポート – SRA OSS
(https://www.sraoss.co.jp/tech-blog/wp-content/uploads/2022/10/pg15_report_20221020.pdf)
• オンライン物理バックアップの排他モードと非排他モードについて
(https://www.slideshare.net/nttdata-tech/postgresql-backup-mode-pgunconf34-nttdata)
• PostgreSQL の INSERT ON CONFLICT と MERGE の簡易性能比較
(https://qiita.com/fujii_masao/items/462bac9f6a107d6134c4)
• PostgreSQL 15 Statistics
(http://peter.eisentraut.org/blog/2022/10/25/postgresql-15-statistics)
• Speeding up sort performance in PostgreSQL 15
(https://www.citusdata.com/blog/2022/05/19/speeding-up-sort-performance-in-postgres-15/)
• Looking ahead at PostgreSQL 15
(https://www.slideshare.net/jkatz05/looking-ahead-at-postgresql-15)
• pg_basebackup could not set compression worker count - unsupported parameter
(http://rhaas.blogspot.com/2022/11/pgbasebackup-could-not-set-compression.html)
37

Thank you!
Masahiko Sawada
@masahiko_sawada
38

PostgreSQL 15の新機能を徹底解説

More Related Content

What's hot (20)

Similar to PostgreSQL 15の新機能を徹底解説 (20)

More from Masahiko Sawada (20)

PostgreSQL 15の新機能を徹底解説