押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)

PostgreSQL Conference Japan 2020
© 2020 NTT DATA Corporation
押さえておきたい、PostgreSQL 13 の新機能!!
2020年11月13日
株式会社NTTデータ藤井雅雄

© 2020 NTT DATA Corporation 22© 2020 NTT DATA Corporation
自己紹介
藤井雅雄
Database Technical Lead @ NTTデータ
データベース研究開発
PostgreSQL 技術支援
PostgreSQLコミッタ
レプリケーション
WAL圧縮
バックアップ進捗確認
pg_bigm(全文検索モジュール)コミッタ
@fujii_masao
v13～
v13にも、新機能パラレルVACUUMにも、対応済！

© 2020 NTT DATA Corporation 3
本講演について
講演資料は、NTTデータのSlideShareアカウント上で公開予定です。
https://www.slideshare.net/nttdata-tech
講演資料に掲載の検証結果は、ノートPC上の簡易計測で取得したものです。
環境や条件などによっては、異なる検証結果になる可能性があるためご了承ください。

PostgreSQL13
2020年9月24日リリースのPostgreSQL最新メジャーバージョン
約170個の新機能や変更点
– 継続的なパフォーマンス改善
– アプリケーション開発の利便性向上
– 運用・監視の機能強化
v13新機能の参考資料
– 篠田の虎の巻「PostgreSQL 13 新機能検証」
– SRA OSS Tech Blog「PostgreSQL 13 検証報告」
https://lets.postgresql.jp/documents/technical/13
開発貢献者は380名
(うち29名が日本在住/日本人)

PostgreSQL13
11月12日に13.1がリリース！
‐ セキュリティ脆弱性3件をクローズ
‐ バグ65件を修正
‐ CVE-2020-25695の性質上、
できるだけ早急のアップデートが推奨

継続的なパフォーマンス改善

7© 2020 NTT DATA Corporation
B-treeインデックスの重複エントリ排除
code name
11 AAA
22 BBB
22 CCC
22 DDD
33 EEE
code
11
22
22
22
33
テーブルB-treeインデックス
‐ B-treeインデックスでは、
各エントリがテーブルへの
ポインタ(TID)を持つ構造
‐ キー値が重複する場合も、
各エントリがポインタを持つ
～v12

code name
11 AAA
22 BBB
22 CCC
22 DDD
33 EEE
code
11
22
22
22
33
code
11
22
33
v13から、
B-treeインデックスで、重複するエントリをまとめてインデックスサイズを削減可能に！
テーブル
B-treeインデックス B-treeインデックス
キー値がの重複エ
ントリ3つについて、
ポインタをリスト化して、
エントリをまとめる
～v12
v13～
v13～
22

=# CREATE INDEX testidx ON test (code) WITH (deduplicate_items = off);
=# ALTER INDEX testidx SET (deduplicate_items = on);
重複エントリを排除するかは、インデックス毎にdeduplicate_itemsオプションで設定可能
on
off
:
:
重複エントリを排除する (デフォルト)
重複エントリを排除しない (v12以前と同じ動き)

code
11
22
code
11
22
22
code
11
22
22
22
code
11
22
エントリ 22 の追加エントリ 22 の追加
重複エントリ排除
ページに収まるため、
重複エントリはそのまま
ページに収まらないため、
重複エントリを排除するページ
インデックスの
ページ分割を回避できる
(凡例)
重複エントリを排除するのは、エントリがページに収まらないとき
重複エントリ排除を遅延させることで、排除処理のオーバーヘッドを回避
CREATE INDEXやREINDEXは、即座に重複エントリを排除する(遅延させない)
インデックスインデックスインデックスインデックス

重複エントリ排除on/offでのインデックスサイズとINSERT性能の比較
‐ integer型カラムに対してインデックス作成
‐ レコード1億件について重複割合を0%(重複なし)、20%、40%、
60%、80%、100%(1億件すべてが重複)と変えながらINSERT
‐ INSERT後のインデックスサイズとINSERT時間を計測

0
500
1000
1500
2000
2500
0 20 40 60 80 100
インデックスサイズ(MB)
重複エントリの割合(%)
on
off
重複排除onでは、
重複エントリの割合が大きいほど、インデックスサイズの削減効果が大きい

80
85
90
95
100
105
0 20 40 60 80 100
INSERT時間(秒)
重複エントリの割合(%)
on
off
重複エントリの割合が小さく、
INSERTオンリーの場合は
重複排除offを検討する価値がある
重複排除onでは、
重複エントリの割合が小さいほど、INSERT時の性能オーバーヘッドが見えやすい

code
11
22
code
11
22
22
code
11
22
22
22
code
11
22
エントリ 22 の追加エントリ 22 の追加
重複エントリ排除
HOTが効かない更新では
ユニークインデックスにも重複エントリが追加されるページ
インデックスの
ページ分割を回避できる
(凡例)
インデックスインデックスインデックスインデックス
非HOTな更新により非HOTな更新により
ユニークユニークユニークユニーク
レコード更新がある場合は、ユニークインデックスでも重複排除onによる
インデックスサイズ削減効果は期待できる！

以下のインデックスでは、deduplicate_items=onでも重複エントリは排除されない
以下のデータ型のカラムに対するインデックス
- 非決定的なCOLLATEを使う文字列型 (text, varchar, char)
- float4, float8, numeric
- jsonb
- コンテナ型 (複合型, 配列, 範囲型など)
INCLUDE句が指定されたインデックス
1
2

インクリメンタル・ソート
aid bid
11 9
11 1
22 5
22 3
33 2
33 4
=# SELECT * FROM tbl ORDER BY aid, bid;
ORDER BYの前半のキーがソート済
(インデックス作成済) でも、テーブル
全体をソートする必要がある
• ソート対象レコード数が多くなり、
ディスクソートに陥りやすい
• LIMIT指定時もテーブル全体の
ソートが必要
～v12
インデックス作成済

v13～
新しいソート方式のインクリメンタル・ソートが利用可能に！
ソート済キーでレコードをグルーピングして、各グループ内でソート
• ソート対象レコード数が少なくなり、ディスクソートに陥りにくい
• LIMIT指定時は一部レコードのみソート
• インクリメンタル・ソートの有効/無効は、
enable_incremental_sortオプションで設定可能
=# SELECT * FROM tbl ORDER BY aid, bid;
aid bid
11 9
11 1
22 5
22 3
33 2
33 4
インデックス作成済

EXPLAIN (ANALYZE on, COSTS off) SELECT * FROM tbl ORDER BY aid, bid LIMIT 100;
Limit (actual time=14548.246..14548.262 rows=100 loops=1)
-> Sort (actual time=14548.245..14548.250 rows=100 loops=1)
Sort Key: aid, bid
Sort Method: top-N heapsort Memory: 29kB
-> Seq Scan on tbl (actual time=0.014..7552.718 rows=100000000 loops=1)
Planning Time: 0.083 ms
Execution Time: 14548.287 ms
ORDER BYとLIMITのクエリの実行プランと実行時間の比較
(1億件のレコードをカラムaid,bidでORDER BYして、LIMITで100件のみ抽出。aidのみにインデックス)
1億件のシーケンシャルスキャンとソートが走り、
実行時間は14秒以上
インクリメンタル・ソートを使わない場合1

-> Gather Merge (actual time=5442.419..5443.274 rows=100 loops=1)
Workers Planned: 2
Workers Launched: 2
Sort Key: aid, bid
Sort Method: top-N heapsort Memory: 29kB
Worker 0: Sort Method: top-N heapsort Memory: 29kB
Worker 1: Sort Method: top-N heapsort Memory: 29kB
-> Parallel Seq Scan on tbl (actual time=0.262..2874.988 rows=33333333 loops=3)
インクリメンタル・ソートを使わない場合 (パラレルクエリ利用時)2
1億件のシーケンシャルスキャンとソートのパラレル実行により、
実行時間は5.4秒まで短縮

-> Incremental Sort (actual time=0.036..0.068 rows=100 loops=1)
Sort Key: aid, bid
Presorted Key: aid
Full-sort Groups: 3 Sort Method: quicksort Average Memory: 26kB Peak Memory: 26kB
-> Index Scan using tblidx on tbl (actual time=0.015..0.046 rows=101 loops=1)
インクリメンタル・ソートを使う3
インクリメンタル・ソートにより、インデックススキャン結果から、
抽出件数に必要な分だけグルーピングしてソートすることで、
実行時間は0.093ミリ秒まで大幅短縮！！

ディスクベース・ハッシュ集約
=# EXPLAIN (ANALYZE on, COSTS off)
SELECT aid, count(*) FROM tbl GROUP BY aid;
HashAggregate (actual time=204.662..204.782 rows=1000 loops=1)
Group Key: aid
Execution Time: 204.871 ms (100万件レコードを集約)
ハッシュがメモリに収まるほどレコード数が少ないため、
ハッシュ集約を選択
ハッシュ集約(HashAggregate)は、ハッシュを作りながらレコードを集約
‐ v12以前では、ハッシュはメモリ(work_mem)に収まる必要がある
‐ ハッシュがメモリに収まらないほどレコードが多い場合は、ハッシュ集約は利用できない
(ディスクを使えるグループ集約を利用)
～v12

GroupAggregate (actual time=46237.428..62486.980 rows=100000 loops=1)
Group Key: aid
Sort Key: aid
Sort Method: external merge Disk: 1369920kB
ハッシュ集約(HashAggregate)は、ハッシュを作りながらレコードを集約
‐ v12以前では、ハッシュはメモリ(work_mem)に収まる必要がある
‐ ハッシュがメモリに収まらないほどレコードが多い場合は、ハッシュ集約は利用できない
(ディスクを使えるグループ集約を利用)
(1億件レコードを集約)
ハッシュがメモリに収まらないほどレコード数が多いため、
グループ集約を選択
～v12

HashAggregate (actual time=26209.786..35445.184 rows=100000 loops=1)
Group Key: aid
Batches: 5 Memory Usage: 4145kB Disk Usage: 1657736kB
Execution Time: 36156.087 ms (1億件レコードを集約)
ハッシュがメモリに収まらないほどレコード数が多いため、
ディスクを使ったハッシュ集約を選択
v13から、ハッシュ集約でもディスクを利用可能に！
ハッシュがメモリに収まらないほどレコードが多い場合も、ハッシュ集約は利用できる
v13～

パラレルVACUUM
テーブル
スキャン
インデックス
VACUUM①
インデックス
VACUUM②
テーブル
VACUUM
インデックス
Cleanup①
インデックス
Cleanup②
ファイル
切り詰め
～v12
インデックスを1つずつ処理
するため、インデックス数が
多いとVACUUM時間は
長くなりやすい

パラレルVACUUM
テーブル
スキャン
インデックス
VACUUM①
インデックス
VACUUM②
テーブル
VACUUM
インデックス
Cleanup①
インデックス
Cleanup②
ファイル
切り詰め
テーブル
スキャン
インデックス
VACUUM①
インデックス
VACUUM②
テーブル
VACUUM
インデックス
Cleanup①
インデックス
Cleanup②
ファイル
切り詰め
テーブルに複数のインデックスが定義されている場合、v13から、
VACUUMのインデックス関連の処理をパラレルに実行可能に！
～v12
v13～
v13～
インデックスを1つずつ処理
するため、インデックス数が
多いとVACUUM時間は
長くなりやすい
複数のインデックスをパラレルに処理す
ることで、VACUUM時間を短縮できる。
リソース消費は増加

パラレルVACUUM
=# VACUUM (PARALLEL n) tbl;
PARALLELオプションで並列数 n を指定可能
オプション未指定時もデフォルトでパラレルVACUUMは実行
パラレルVACUUMはVACUUMコマンドで実行可能
パラレルVACUUMの並列数は以下の最小値
‐VACUUM対象テーブルに定義されているインデックス数
‐PARALLELオプションで指定された値
‐max_parallel_maintenance_workersパラメータの値

パラレルVACUUM
=# VACUUM (PARALLEL 0, VERBOSE on) t;
INFO: vacuuming "public.t"
INFO: scanned index "idx1" to remove 50000000 row versions
DETAIL: CPU: user: 9.09 s, system: 1.41 s, elapsed: 11.44 s
...
CPU: user: 31.04 s, system: 7.33 s, elapsed: 41.26 s.
パラレルVACUUMの性能改善効果の確認
‐ レコード件数1億のテーブルにインデックスを3つ作成 (各インデックスのサイズは2142MB)
‐ テーブルから5千万件をDELETEして、VACUUMを実行
各インデックスの処理の分だけ
時間がかかる

パラレルVACUUM
=# VACUUM (PARALLEL 2, VERBOSE on) t;
INFO: vacuuming "public.t"
INFO: launched 2 parallel vacuum workers for index vacuuming (planned: 2)
INFO: scanned index "idx2" to remove 50000000 row versions by parallel vacuum worker
INFO: scanned index "idx3" to remove 50000000 row versions by parallel vacuum worker
...
CPU: user: 12.57 s, system: 4.38 s, elapsed: 20.36 s.
パラレルVACUUMの性能改善効果の確認
‐ レコード件数1億のテーブルにインデックスを3つ作成 (各インデックスのサイズは2142MB)
‐ テーブルから5千万件をDELETEして、VACUUMを実行
インデックスをパラレル処理した分だけ
VACUUMを高速化
メインのバックエンドがインデックスidx1を処理して、
パラレル・ワーカー2つがインデックスidx2とidx3を
処理

パラレルVACUUM
以下では、パラレルVACUUMを利用できない
‐ VACUUM対象のテーブルにインデックスが未定義または1つのみ
‐ インデックスサイズがmin_parallel_index_scan_sizeパラメータの値より小さい
‐ パラレルVACUUM未対応のインデックスのみを利用
(PostgreSQL組み込みのインデックスはすべて対応)
‐ PARALLELオプションまたはmax_parallel_maintenance_workersパラメー
タで並列数0を指定
‐ VACUUM FULL
‐ autovacuum

アプリケーション開発の利便性向上

FETCH FIRST WITH TIES
問合せ結果からn件返却するクエリ
=# SELECT * FROM tbl ORDER BY id LIMIT n;
=# SELECT * FROM tbl ORDER BY id FETCH FIRST n ROWS ONLY;
FETCH FIRSTは、v8.4からサポートされた、
LIMIT句と同じ結果を実現する標準SQL:2008の構文
どちらもn件返却を指定する構文

v13から、FETCH FIRST WITH TIESがサポートされ、
同じ順位のレコードも返却可能に！
SELECT * FROM tbl
ORDER BY score DESC
FETCH FIRST 3 ROWS ONLY;
name | score
------+-------
XXX | 98
AAA | 90
FFF | 86
(3 rows)
SELECT * FROM tbl
ORDER BY score DESC
FETCH FIRST 3 ROWS WITH TIES;
name | score
------+-------
XXX | 98
AAA | 90
FFF | 86
CCC | 86
ZZZ | 86
(5 rows)
上位n件を返却して、
n番目のレコードと
ORDER BYキーが
同じ値のレコードも返却
v8.4～ v13～

=# SELECT * FROM tbl FETCH FIRST 3 ROWS WITH TIES;
ERROR: WITH TIES cannot be specified without ORDER BY clause
FETCH FIRST WITH TIESはORDER BYの指定が必須
(FETCH FIRST ONLYはORDER BY未指定でも動作可能)
ORDER BY未指定で
WITH TIESを使うと
エラーが発生

Unicode文字列の正規化関数
v13から、normalize関数を使って、Unicode文字列を正規化可能に！
=# SELECT normalize('ｱｲｳｴｵ', NFKC);
正規化対象の文字列正規化形式
• NFC (デフォルト)
• NFD
• NFKC
• NFKD

Unicode文字列のNFKCでの正規化例
normalize
------------
アイウエオ
(1 row)
=# SELECT normalize('ＡｂＣｄＥ１２３', NFKC);
normalize
-----------
AbCdE123
(1 row)
=# SELECT normalize('㌢㋿㊨⑤Ⅷ㈲', NFKC);
normalize
-----------------------
センチ令和右5VIII(有)
(1 row)
半角カタカナを全角カタカナに変換
全角英数字を半角英数字に変換
記号や環境依存文字を変換

正規化関数の応用例
normalize関数により、正規化を考慮した全文検索が可能に！
=# CREATE INDEX testidx ON test
USING gin (normalize(col, NFKC) gin_bigm_ops);
=# SELECT * FROM test
WHERE normalize(col, NFKC)
LIKE likequery(normalize('PostgreSQLバージョン13', NFKC));
col
--------------------------------------------
PostgreSQLバージョン13の新機能
PostgreSQLﾊﾞｰｼﾞｮﾝ13の新機能
PostgreSQLバージョン⑬の新機能
ＰｏｓｔｇｒｅＳＱＬバージョン１３の新機能
(4 rows)
全文検索インデックスの作成時と
検索時にnormalize関数を指定
英数字・カタカナの全角半角や記号の区別なく
全文検索が可能に！

Unicode文字列の正規化の性能
正規化はv14で大幅に性能改善予定！
3.8 3.8
69.2 69.2
0.7 0.7 1.0 1.0
0
20
40
60
80
NFD NFKD NFC NFKC
正
規
化
に
か
か
る
時
間
(
秒
)
v13
v14
日本語を含む19MBの
文字列(※1)の正規化にかかる
時間をv13とv14で比較
(※1) PostgreSQL12日本語ドキュメントの各SGMLファイルをテーブルレコードとして取り込み、そのすべてのレコード(合計サイズ19MB)に対して下記クエリで時間を計測
EXPLAIN ANALYZE SELECT normalize(content, NFKC) FROM doc;

正規化関数利用の制限
=# SHOW server_encoding ;
server_encoding
-----------------
EUC_JP
ERROR: Unicode normalization can only be performed if server encoding is UTF8
normalize関数を使えるのは、サーバエンコーディングがUTF-8のときのみ
UTF-8以外のサーバエンコーディングで
normalize関数を使うとエラーが発生

運用・監視の機能強化

バックアップの進捗確認
v12以前から、--progressオプションを指定することで、
バックアップ取得の進捗状況をクライアント側で確認することは可能
$ pg_basebackup -h 192.168.0.x -D /bkp/data --progress
1339087/2894148 kB (46%), 2/4 tablespaces
バックアップDBデータ

バックアップの進捗確認
v13からは、
バックアップ取得の進捗状況をサーバ側でもSQLで確認することが可能に！
$ psql
=# SELECT * FROM pg_stat_progress_basebackup;

pg_stat_progress_basebackup
-[ RECORD 1 ]:--------+---------------------------
pid | 58783
phase | streaming database files
backup_total | 2963609088
backup_streamed | 1372009984
tablespaces_total | 4
tablespaces_streamed| 3
– バックアップを担当するサーバ側プロセスのPID
– バックアップ取得の現在の処理フェーズ
– バックアップ対象データのトータルサイズ
– 現在転送済み(取得済み)のバックアップのサイズ
– バックアップ対象のテーブルスペースの数
– 現在転送済み(取得済み)のテーブルスペースの数

PostgreSQLのコマンド進捗機能
サポート開始
バージョン
コマンド進捗確認ビュー進捗確認対象のコマンド
v9.6 pg_stat_progress_vacuum VACUUM, autovacuum
v12
pg_stat_progress_cluster CLUSTER, VACUUM FULL
pg_stat_progress_create_index CREATE INDEX, REINDEX
v13
pg_stat_progress_basebackup pg_basebackup
pg_stat_progress_analyze ANALYZE, autoanalyze
v14 pg_stat_progress_copy (パッチ提案中) COPY TO / FROM

バックアップ・マニフェスト
バックアップをリストアしてDBデータを復旧したいとき、
バックアップがリストアできる正常状態なのか、破損しているのか判断つかない！？
バックアップ
バックアップで困るケース

v13からは、
バックアップ取得時に、バックアップの妥当性を検証するための情報である
バックアップ・マニフェスト (backup_manifest) を取得可能に！
pg_verifybackup コマンドを使って、バックアップ・マニフェストから
バックアップの妥当性を検証可能に！
1
2
backup_manifest

$ pg_basebackup -h 192.168.0.x -D /bkp/data
$ ls /bkp/data
PG_VERSION pg_dynshmem pg_replslot pg_tblspc
backup_label pg_hba.conf pg_serial pg_twophase
backup_manifest pg_ident.conf pg_snapshots pg_wal
base pg_logical pg_stat pg_xact
global pg_multixact pg_stat_tmp postgresql.auto.conf
pg_commit_ts pg_notify pg_subtrans postgresql.conf
‐ pg_basebackupはデフォルトでバックアップにbackup_manifestファイルを含める
‐ backup_manifestを取得したくない場合は、--no-manifestオプションを指定

$ cat /bkp/data/backup_manifest
{ "PostgreSQL-Backup-Manifest-Version": 1,
"Files": [
{ "Path": "AAA", "Size": 224, "Last-Modified": "2020-05-14 15:47:21 GMT",
"Checksum-Algorithm": "CRC32C", "Checksum": "0dc6dc58" },
{ "Path": "BBB", "Size": 800, "Last-Modified": "2020-05-14 15:46:01 GMT",
"Checksum-Algorithm": "CRC32C", "Checksum": "23464490" },
...
バックアップ内のファイルBBBについて
ファイルパスやサイズ、最終変更日時、チェックサム、チェックサム・アルゴリズムを記録
バックアップに含まれるすべてのファイルについて、
妥当性チェックに必要な情報をJSON形式で一覧化

$ pg_verifybackup /bkp/data
バックアップの妥当性検証に成功
backup successfully verified
バックアップ取得時には存在していたファイルが、現在のバックアップから消えている
pg_verifybackup: error: "PG_VERSION" is present in the manifest but not on disk
バックアップ取得時にはなかったファイルが、現在のバックアップに存在している
pg_verifybackup: error: "hoge" is present on disk but not in the manifest
バックアップ取得時と現在とでファイルのサイズが異なる
pg_verifybackup: error: "PG_VERSION" has size 0 on disk but size 3 in the manifest
バックアップ取得時と現在とでファイルの内容(チェックサム)が異なる
pg_verifybackup: error: checksum mismatch for file "PG_VERSION"

SQLの構文解析
SQLのプラン生成
SQLの実行
SQL文
SQL実行結果
pg_stat_statementsで取集されるのは
「 SQLの実行」にかかる時間と回数のみ
複雑なSQLで、プラン生成に時間がかかっても、
pg_stat_statementsからはその状況を把握でき
ない
1
2
3
3
～v12

「 SQLのプラン生成」にかかる時間と回数も
収集可能に！
プラン生成に時間のかかる複雑なSQLについても、
状況をpg_stat_statementsで把握できる
v13～
SQLの構文解析
SQLのプラン生成
SQLの実行
SQL文
SQL実行結果
1
2
3
2

レプリケーション接続先を手軽に再設定
スタンバイ側で、primary_conninfoパラメータにレプリケーション接続先を設定
$ cat $PGDATA/postgresql.conf
primary_conninfo = 'host=x.x.x.x port=5432 user=repuser'
マスタスタンバイ
WAL転送
接続要求
x.x.x.x:5432

マスタ
スタンバイ
新マスタ
フェイル
オーバ
WAL転送
接続要求
v12以前では、レプリケーション接続先を再設定するには、スタンバイの再起動が必要
x.x.x.x:5432
y.y.y.y:9999
primary_conninfo = 'host=y.y.y.y port=9999 user=repuser'
再起動
～v12

マスタ
スタンバイ
新マスタ
フェイル
オーバ
WAL転送
接続要求
v13から、設定ファイルの再読み込みで、レプリケーション接続先を再設定可能に！
x.x.x.x:5432
y.y.y.y:9999
primary_conninfo = 'host=y.y.y.y port=9999 user=repuser'
設定ファイル再読み込み
$ pg_ctl reload
v13～

primary_conninfoを空にして設定ファイルを再読み込みすることで、
スタンバイ側でWAL受信を一時停止(walreceiverを停止)可能に！
マスタスタンバイ
WAL転送
接続要求
x.x.x.x:5432
primary_conninfo = ''
設定ファイル再読み込み
$ pg_ctl reload
一時停止

さいごに
ぜひ新機能を
お試しいただければ！！
PostgreSQL13は約170個の新機能や変更点をサポートして、
性能・機能・運用について着実に改善！！

その他、記載されている会社名、商品名、又はサービス名は、
各社の登録商標又は商標です。

EXPLAINでのWAL生成量の出力
=# EXPLAIN (ANALYZE on, WAL on, COSTS off)
UPDATE t SET j = j + 1 WHERE i < 500001;
QUERY PLAN
-----------------------------------------------------------------------
Update on t (actual time=728.119..728.119 rows=0 loops=1)
WAL: records=999962 fpi=4431 bytes=88209808
-> Seq Scan on t (actual time=34.696..101.025 rows=500000 loops=1)
Filter: (i < 500001)
Rows Removed by Filter: 500000
(7 rows)
‐ WALオプションonで、SQLによる
WAL生成に関する情報を出力
‐ WALオプションはデフォルトoff

psqlコマンドプロンプトのデフォルト表示の変更
=# BEGIN;
BEGIN
=# SELECT 1/0;
ERROR: division by zero
=# ROLLBACK;
ROLLBACK
=#
=# BEGIN;
BEGIN
=*# SELECT 1/0;
ERROR: division by zero
=!# ROLLBACK;
=#
‐ トランザクション途中のプロンプトが =# から =*# に変更
‐ エラー発生後からROLLBACKまでのプロンプトが =# から =!# に変更
v13～～v12

-> Index Scan using tblidx2 on tbl (actual time=0.005..0.035 rows=100 loops=1)
ORDER BYのカラムすべてに対して、マルチカラムインデックスを作成
(カラム aid, bid のマルチカラムインデックス)
4
インデックススキャン結果から、必要な件数だけ抽出することで、
実行時間は0.059ミリ秒まで短縮

押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)

Similaire à 押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料) (20)

Plus de NTT DATA Technology & Innovation

Plus de NTT DATA Technology & Innovation (20)

Dernier

Dernier (8)

押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)