2. 2020/11/28
平田 哲
PostgreSQL13 新機能紹介

3. 自己紹介
3
平田 哲（HIRATA, Satoshi）
id: debility
Japan PostgreSQL Users Group
Fukuoka.pm
Program, Server, Network, and “Nomikai”
Main Weapon: Custom Dual Squelcher
icon: © mutsuking

4. 今日の話
4
PostgreSQL13 新機能の紹介をします。
・SQL機能の追加
・大規模環境に対する拡張について
・信頼性の向上について
・運用性の向上について
・将来バージョンへの対応
・その他
・非互換な変更について

5. 質問や気になったことについて
5
質問はチャットに書いていただければ、回答で
きる限り回答します。
とは言え即答できないケースもあると思います
ので、その場合はAsk the speaker枠を活用
したいと思います。

6. Ask the speaker枠について
6
本セッションの直後、15:15-16:00 D会場を
Ask the speaker枠として設けています。
本セッションの内容で気になったことや、その
他PostgreSQLに関する質問をざっくばらんに
話せればと思いますので、もし気になる点など
ありましたらご活用ください。

7. 参考文書
7
篠田の虎の巻
「PostgreSQL 13 新機能検証」日本語版
https://h50146.www5.hpe.com/products/software/oe/linux/
mainstream/support/lcc/pdf/PostgreSQL_13_GA_New_Feature
s_ja_20200927-1.pdf
SRA OSS,inc
PostgreSQL 13 検証レポート
https://www.sraoss.co.jp/tech-blog/wp-
content/uploads/2020/07/pg13_report_0728.pdf

8. PostgreSQLについて

9. PostgreSQL
9
多機能 RDBMS
初版は23年前、前身のPOSTGRESの初版は
31年前（1989年）
1社主導ではないOSS

10. PostgreSQL
10
これまでの主要機能追加
8.0 PITR/ Wndows
9.0 レプリケーション
9.1 Seriaalizable SI
9.2 多CPUコア対応
9.4 バイナリ JSON型
9.6 パラレルクエリ
10 論理レプリケーション
11 JITコンパイル
12 テーブルAM

11. 日本PostgreSQLユーザ会
11
Slackにぜひ参加してください。
https://postgresql-hackers-jp.herokuapp.com/
ここに、メールアドレスを入力して、GET MY INVITE (私の
招待を受けます)押してください。

12. SQL機能の追加

13. SQLの追加
13
・FETCH FIRST WITH TIES
・JSON Pathでdatetime()メソッドに対応

14. FETCH FIRST WITH TIES
14
db1=# CREATE TABLE t_rank (id int, score int);
db1=# INSERT INTO t_rank VALUES (1, 100), (2, 90), (3, 90), (4,
90), (5, 85), (6, 85), (7, 80), (8, 80), (9, 75), (10, 60);
db1=# SELECT * FROM t_rank;
id | score
----+-------
1 | 100
2 | 90
3 | 90
4 | 90
5 | 85
6 | 85
7 | 80
8 | 80
9 | 75
10 | 60
(10 rows)

15. FETCH FIRST WITH TIES
15
db1=# SELECT * FROM t_rank ORDER BY score DESC OFFSET 0 ROWS
FETCH FIRST 3 ROWS ONLY;
id | score
----+-------
1 | 100
3 | 90
2 | 90
(3 rows)
db1=# SELECT * FROM t_rank ORDER BY score DESC OFFSET 0 ROWS
FETCH FIRST 3 ROWS WITH TIES;
id | score
----+-------
1 | 100
2 | 90
3 | 90
4 | 90
(4 rows)

16. JSON Pathでdatetime()メソッドに対応
16
db1=# SELECT jsonb_path_query('["12:30:54", "9:10:00",
"13:20:10"]', '$[*].datetime() ? (@ > "12:00:00".datetime())');
jsonb_path_query
------------------
"12:30:54”
"13:20:10”
(2 rows)

17. JSON Pathでdatetime()メソッドに対応
17
db1=# SELECT jsonb_path_query( '{"timestamp": "2020-06-06
05:05:05 PM +09:00"}'::jsonb, '$.timestamp.datetime("YYYY-MM-DD
HH:MI:SS AM TZH:TZM")’);
jsonb_path_query
-----------------------------
"2020-06-06T17:05:05+09:00”
(1 row)

18. JSON Pathでdatetime()メソッドに対応
18
db1=# SELECT jsonb_path_query_tz( '["12:30:54", "9:10:00",
"13:20:10"]', '$[*].datetime() ? (@ < "12:00:00
+08".datetime())’);
jsonb_path_query_tz
---------------------
"12:30:54”
"09:10:00”
(2 rows)

19. 大規模環境に対する拡張について

20. 大規模環境に対する拡張について
20
・B-Treeインデックスの重複排除
・パラレル処理の拡張
・WAL出力の抑制

21. B-Tree インデックスの重複排除
21
B-Tree インデックスでは重複排除処理が標
準で動作するようになりました。
ストレージ容量と I/O を削減することができま
す。

22. B-Tree インデックスの重複排除
22
キー値 ヒープTID
データ1 TID 1
データ2 TID 2
データ2 TID 3
データ2 TID 4
データ3 TID 5
キー値 ヒープTID
データ1 TID 1
データ2 TID 2, TID 3, TID 4
データ3 TID 5
PostgreSQL13これまで

23. B-Tree インデックスの重複排除
23
https://www.sraoss.co.jp/tech-blog/wp-content/uploads/2020/07/pg13_report_0728.pdf
db1=# INSERT INTO btree_text SELECT 'foo' FROM generate_series(1,100000);

24. B-Tree インデックスの重複排除
24
https://www.sraoss.co.jp/tech-blog/wp-content/uploads/2020/07/pg13_report_0728.pdf
遅延処理方式により、実行時間増は軽微

25. B-Tree インデックスの重複排除
25
重複排除が効かない場合
・データ型
・非決定的なCOLLATEを使った文字列型
・real, double precision
・numeric
・コンテナ型（配列、複合型、範囲型、JSONB）
・INCLUDEを伴うインデックス

26. パラレル処理の拡張
26
テーブルに複数のインデックスが作成されて
いる場合、VACUUM 処理が並列に行われる
ようになりました。

27. パラレル処理の拡張
27
(SQL で実行する場合)
VACUUM (PARALLEL parallel_degree) table
(シェルで実行する場合)
vacuumdb --parallel=parallel_degree --table table
並列度の指定方法

28. WAL出力の抑制
28
wal_level パラメーターが minimal に設定され
ている場合に、WAL 出力が抑制される構
文が増えました。

29. 信頼性の向上について

30. 信頼性の向上について
30
・バックアップの信頼性向上
・ストリーミング・レプリケーションの動的構成
変更

31. バックアップの信頼性向上
31
バックアップの整合性をチェックできるようになりま
した。
pg_basebackup コマンド等によるベース・バック
アップにはファイル単位のサイズとチェックサムが取
得され、バックアップ先に保存されます。
取得したバックアップの整合性はpg_verifybackup
コマンドでチェックすることができます。

32. ストリーミング・レプリケーションの動的構成変更
32
ストリーミング・レプリケーションのスタンバイ・
インスタンスで使用する各種パラメーターは動
的に変更できるようになりました。
この新機能により、プライマリ・インスタンス
障害時にスタンバイ・インスタンスを再起動す
る必要がなくなりました。

33. 運用性の向上について

34. 運用性の向上について
34
・インクリメンタルソート
・ディスク・ベースのハッシュ集約
・パーティション・テーブルの論理レプリケーション
・モニタリング機能の強化
・実行計画作成と WAL 出力量のトラッキング
・待機イベントの追加

35. インクリメンタルソート
35
既にソートされている結果を利用して、残る部
分は追加でソートする実行プラン

36. インクリメンタルソート
36
（テーブル作成）
db1=# CREATE TABLE t_log (dt timestamp(0), severity text,
message text);
（ダミーデータを 1 万件投入）
db1=# INSERT INTO t_log SELECT
now() + ((g / 2) || 's')::interval,
CASE g % 3 WHEN 0 THEN 'LOG' WHEN 1 THEN 'ERROR' ELSE 'FATAL'
END,
md5(g::text)
FROM generate_series(1, 10000) g;

37. インクリメンタルソート
37
（テーブル内容）
db1=# SELECT * FROM t_log;
dt | severity | message
--------------------+-------+----------------------------------
2020-05-25 14:09:51 | ERROR | c4ca4238a0b923820dcc509a6f75849b
2020-05-25 14:09:52 | FATAL | c81e728d9d4c2f636f067f89cc14862c
2020-05-25 14:09:52 | LOG | eccbc87e4b5ce2fe28308fd9f2a7baf3
2020-05-25 14:09:53 | ERROR | a87ff679a2f3e71d9181a67b7542122c
2020-05-25 14:09:53 | FATAL | e4da3b7fbbce2345d7772b0674a318d5
: 後略
（インデックス作成、VACUUM ANALYZE）
db1=# CREATE INDEX ON t_log (dt);
db1=# VACUUM (ANALYZE) t_log;

38. インクリメンタルソート
38
（インクリメンタルソートを使わない場合）
db1=# SET enable_incrementalsort TO off;
db1=# EXPLAIN (ANALYZE)
SELECT * FROM t_log WHERE dt > ' 2020-05-25 14:10'
ORDER BY dt, severity, message LIMIT 1000;
QUERY PLAN
----------------------------------------------------------------------------
Limit (cost=765.86..768.36 rows=1000 width=46)
(actual time=3.021..3.197 rows=1000 loops=1)
-> Sort (cost=765.86..790.80 rows=9974 width=46)
(actual time=3.019..3.085 rows=1000 loops=1)
Sort Key: dt, severity, message
Sort Method: top-N heapsort Memory: 127kB
-> Seq Scan on t_log (cost=0.00..219.00 rows=9974 width=46)
(actual time=0.013..1.470 rows=9981 loops=1)
Filter: (dt > '2020-05-25 14:10:00'::timestamp without time zone)
Rows Removed by Filter: 19
Planning Time: 0.148 ms
Execution Time: 3.309 ms
(9 rows)

39. インクリメンタルソート
39
（インクリメンタルソートを使った場合）
db1=# SET enable_incrementalsort TO on;
db1=# EXPLAIN (ANALYZE)
SELECT * FROM t_log WHERE dt > ' 2020-05-25 14:10'
ORDER BY dt, severity, message LIMIT 1000;
QUERY PLAN
----------------------------------------------------------------------------
Limit (cost=0.38..74.06 rows=1000 width=46)
(actual time=0.031..0.599 rows=1000 loops=1)
-> Incremental Sort (cost=0.38..735.25 rows=9974 width=46)
(actual time=0.030..0.534 rows=1000 loops=1)
Sort Key: dt, severity, message
Presorted Key: dt
Full-sort Groups: 32 Sort Method: quicksort Average
Memory: 27kB Peak Memory: 27kB
-> Index Scan using t_log_dt_idx on t_log
(cost=0.29..379.83 rows=9974 width=46)
(actual time=0.011..0.333 rows=1001 loops=1)
Index Cond:
(dt > '2020-05-25 14:10:00'::timestamp without time zone)
Planning Time: 0.107 ms
Execution Time: 0.649 ms
(9 rows)

40. ディスク・ベースのハッシュ集約
40
ハッシュ・テーブルを操作する処理はメモリー
使用量の上限を超えるとストレージ上で
行われるようになりました。
従来はメモリー使用量に上限が無かったため、
OOM Killer の対象になることがありました。

41. ディスク・ベースのハッシュ集約
41
ハッシュ集約：GROUP BYを使った集約の問い合わ
せで使われるプラン要素
これまでは十分なメモリ量がwork_memで設定され
ている場合のみ使われていた
work_memが不足する場合は代わりにグループ集
約プランが使われるが、これは事前にソート処理が
必要となるため性能が劣るケースがあった

42. ディスク・ベースのハッシュ集約
42
実行コストおよび所要時間
グループ集約＞ストレージハッシュ集約＞ハッシュ集約
データが増えて、work_memが足りずにハッシュ集約が使わ
れなくなった場合の極端な性能劣化を防ぐことができる

43. パーティション・テーブルの論理レプリケーション
43
パーティション・テーブルの論理レプリケーショ
ンが実現できるようになりました。

44. モニタリング機能の強化
44
ANALYZE 文や pg_basebackup コマンドの
実行状況をリアルタイムに確認できるカタロ
グが追加されました。
またキャッシュのヒット率や I/O の状況を確認
できるようになりました。

45. 実行計画作成と WAL 出力量のトラッキング
45
実行計画作成時やSQL文実行時のWAL出力
量がトラッキングできるようになりました。
pg_stat_statements モジュールや EXPLAIN
文で確認できます。

46. 待機イベントの追加
46
監視できる待機イベントがいくつか追加され
ました。
pg_stat_activity カタログで確認できます。

47. 将来バージョンへの対応

48. 将来バージョンへの対応
48
・64ビット・トランザクションID対応
・並列実行の拡張
・PUBLICATIONの拡張

49. 64ビット・トランザクションID対応
49
64ビット・トランザクションIDを示す xid8 デー
タ型と、このデータ型を扱う各種関数群が追
加されました。

50. 並列実行の拡張
50
COPY、INSERT、VACUUM 等のパラレル化を
実装できるようにするため、パラレル・
ワーカー・プロセス間でページロックとリレー
ション拡張ロックを競合させて排他的に処
理するようになりました。

51. PUBLICATIONの拡張
51
テーブル以外のオブジェクトを PUBLICATION
に追加できる準備が行われました。

52. その他

53. その他
53
・pg_bench拡張
・pg_rewind拡張

54. pg_bench拡張
54
・--partitionオプションの追加
・--partition-methodオプションの追加
・サーバ側での標準シナリオテストデータ作成
・標準シナリオのテストデータ生成中の進捗表
示が変更

55. pg_rewind拡張
55
・自動クラッシュリカバリ
・リカバリ設定作成オプションの追加
・WALアーカイブ 利用の自動化

56. 非互換な変更について

57. 非互換な変更について
57
・createuserコマンドの --adduser、--no-
adduserオプションが削除
・CSV形式ログの末尾にバックエンドタイプが
追記される
・疑似データ型opaqueを廃止
・OpenSSL1.0.0以下はサポート対象外
・psqlコマンドのデフォルトプロンプトが変更

58. 非互換な変更について
58
・to_date、to_timestampのTMがロケールに応
じた出力になる
・リカバリの一時停止中にプロモーションが行
われた場合はプロモーションを優先
・抽象型を返す関数はパーティション・キーの
値として使用できない（PostgreSQL12.2以
前にバックポートされた）

59. 非互換な変更について
59
・待機イベントの名前が変更
・SIMLAR TO ... ESCAPE NULL がNULLを返
す
・effective_io_concurrency値の意味が変更

60. まとめ

61. まとめ
61
PostgreSQL13は変更が少なめのメジャーリ
リースなので、比較的バージョンアップしやす
いのではないかと思います。

62. （再掲）Ask the speaker枠について
62
本セッションの直後、15:15-16:00 D会場を
Ask the speaker枠として設けています。
本セッションの内容で気になったことや、その
他PostgreSQLに関する質問をざっくばらんに
話せればと思いますので、もし気になる点など
ありましたらご活用ください。

63. ご清聴ありがとうございました。

64. Appendix:並列VACUUM

65. 並列VACUUM
65
複数のインデックスが存在する1つのテーブル
に対して、各インデックスごとにVACUUMを実
行できるようになった
並列数は、テーブル内のインデックス数と、
max_parallel_meaintenance_workersで
指定された値の小さいほうが採用される
（parallel_degreeにて設定可能）

66. 並列VACUUM
66
https://blog.dbi-services.com/postgresql-13-parallel-vacuum-for-indexes/
postgres=# create table t1 as select i as a, i::text as b, now()
as c from generate_series(1,3000000) i;
SELECT 3000000
postgres=# create index i1 on t1(a);
CREATE INDEX
postgres=#
postgres=# create index i2 on t1(b);
CREATE INDEX
postgres=# create index i3 on t1(c);
CREATE INDEX

67. 並列VACUUM
67
https://blog.dbi-services.com/postgresql-13-parallel-vacuum-for-indexes/
postgres=# create table t1 as select i as a, i::text as b, now()
as c from generate_series(1,3000000) i;
SELECT 3000000
postgres=# create index i1 on t1(a);
CREATE INDEX
postgres=#
postgres=# create index i2 on t1(b);
CREATE INDEX
postgres=# create index i3 on t1(c);
CREATE INDEX

68. 並列VACUUM
68
https://blog.dbi-services.com/postgresql-13-parallel-vacuum-for-indexes/
postgres=# update t1 set a=5,b='ccc',c=now() where mod(a,5)=0;
UPDATE 600000
postgres=# vacuum (parallel 4) t1;
VACUUM
postgres 16688 15925 13 07:30 ? 00:01:07 postgres:
postgres postgres [local] VACUUM
postgres 19184 15925 0 07:39 ? 00:00:00 postgres:
parallel worker for PID 16688
postgres 19185 15925 0 07:39 ? 00:00:00 postgres:
parallel worker for PID 16688

69. 並列VACUUM
69
https://blog.dbi-services.com/postgresql-13-parallel-vacuum-for-indexes/
postgres=# vacuum (parallel 4, verbose true) t1;
INFO: vacuuming "public.t1"
INFO: launched 2 parallel vacuum workers for index vacuuming (planned: 2)
INFO: scanned index "i2" to remove 600000 row versions by parallel vacuum worker
DETAIL: CPU: user: 0.24 s, system: 0.06 s, elapsed: 0.89 s
INFO: scanned index "i1" to remove 600000 row versions
DETAIL: CPU: user: 0.17 s, system: 0.10 s, elapsed: 1.83 s
INFO: scanned index "i3" to remove 600000 row versions by parallel vacuum worker
DETAIL: CPU: user: 0.16 s, system: 0.14 s, elapsed: 1.69 s
INFO: scanned index "i4" to remove 600000 row versions by parallel vacuum worker
DETAIL: CPU: user: 0.25 s, system: 0.09 s, elapsed: 1.17 s
INFO: "t1": removed 600000 row versions in 20452 pages
DETAIL: CPU: user: 0.17 s, system: 0.16 s, elapsed: 1.43 s
INFO: index "i1" now contains 3000000 row versions in 14308 pages
DETAIL: 600000 index row versions were removed.
1852 index pages have been deleted, 640 are currently reusable.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
INFO: index "i2" now contains 3000000 row versions in 14305 pages
DETAIL: 600000 index row versions were removed.
1851 index pages have been deleted, 640 are currently reusable.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
（後略）

70. 並列VACUUM
70
VACUUM FULLと同時に利用できない
インデックスサイズが
min_parallel_index_scan_sizeよりも大きい場
合のみ、並列実行の対象内となる