Open Source Conference 2021 Online/Hiroshima PostgreSQL 14 がやってくる！ ぬこ＠横浜 @nuko_yokohama

自己紹介 ● ぬこ＠横浜 (@nuko_yokohama) ● にゃーん ● 趣味でポスグレをやってる者だ ● 今日は JPUG の人として発表します

PostgreSQL のこれまで

PostgreSQL とは何か ? ● オープンソース ORDBMS ● 20 年以上の歴史 ● 日本国内でも広く使われている ● 今でも絶賛開発中 – 年に 1 回のメジャーバージョンアップ – 3 ヶ月に 1 回のマイナーバージョンアップ

PostgreSQL の歴史（ PostgreSQL 10 ～） バージョン リリース日 主な変更 10 2017-10-05 宣言パーティション ロジカルレプリケーション 11 2018-10-18 パーティション機能改善 ストアド・プロシージャ JIT （実行時コンパイル） 12 2019-10-03 リカバリ手順変更 (recovery.conf の削除 ) テーブルアクセスメソッド 生成列 13 2020-09-24 Btree インデックスの改善 パーティションの集計の性能改善 インクリメンタル・ソート 14 2021-09-?? ？？？

PostgreSQL 14 の開発状況 ● Commitfest （ 2020.7 ～ 2021.3 ） ● beta1 （ 2021.5.20 ） ● beta2 （ 2021.6.24 ） ● beta3 （ 2021.8.13 ） ● Release Candidate （ 2021.9.23 ）← もうすぐ！ ● PostgreSQL 14.0 　（ 2021.9.30 ）←予定では

PostgreSQL 14 新機能

修正概要 ● リリースノートに書かれている修正項目は 195 項目 (beta3) カテゴリ 項目数 E.1.3.1. Server 7 E.1.3.1.1. Vacuuming 12 E.1.3.1.2. Partitioning 3 E.1.3.1.3. Indexes 5 E.1.3.1.4. Optimizer 5 E.1.3.1.5. General Performance 9 E.1.3.1.6. Monitoring 3 E.1.3.1.7. System Views 11 E.1.3.1.8. Authentication 4 E.1.3.1.9. Server Configuration 6 カテゴリ 項目数 E.1.3.2. Streaming Replication and Recovery 11 E.1.3.2.1. Logical Replication 10 E.1.3.3. SELECT, INSERT 6 E.1.3.4. Utility Commands 12 E.1.3.5. Data Types 13 E.1.3.6. Functions 21 E.1.3.7. PL/pgSQL 3 E.1.3.8. Client Interfaces 4 E.1.3.9. Client Applications 4 E.1.3.9.1. psql 8 E.1.3.10. Server Applications 4 カテゴリ 項目数 E.1.3.11. Documentation 2 E.1.3.12. Source Code 12 E.1.3.13. Additional Modules 10 E.1.3.13.1. pg_stat_statements 4 E.1.3.13.2. postgres_fdw 6 今日は一部だけ 紹介します

E.1.3.1. Server ● 以下の定義済みロールが追加された – pg_read_all_data ● 全てのスキーマへの USAGE ● テーブル等への SELECT – pg_write_all_data ● 全てのスキーマへの USAGE ● テーブル等への INSERT/UPDATE/DELETE – pg_database_owner ● 全てのデータベース所有者は暗黙のうちにこのロールに含まれる

E.1.3.1. Server ● pg_read_all_data/pg_write_all_data を付与したユーザの挙動を調査した。 – PostgreSQL 14 beta3 での結果 CREATE TABLE (*1) SELECT INSERT UPDATE DELETE TRUNCATE pg_read_alll_data × ○ × × × × pg_write_alll_data × × ○ × (*2) × (*2) × pg_read_alll_data pg_write_alll_data × ○ ○ ○ ○ × (*1) public スキーマを除く (*2) WHERE 句なしの UPDATE/DELETE はエラーにならない (*2) の挙動が実に 面白い・・・ ( バグじゃない )

E.1.3.1.1. Vacuuming ● 削除可能なインデックスエントリの数が重要でない場合に、バキューム がインデックスのバキューム処理をスキップできるようになった – INDEX_CLEANUP オプションの dafalut=auto になり自動で上記 の最適化を実施する ● 多数のリレーションを持つデータベースのバキューム処理を高速化した

E.1.3.1.2. Partitioning ● パーティションテーブルの更新 / 削除のパフォーマンスを改善 ● ノンブロッキングでパーティションを切り離し可能になった

E.1.3.1.4. Optimizer ● Optimizer 改善については、まだ自分もきちんと理解できない項 目もあって検証できていないものもあります・・・。 ● IF NOT EXISTS つきの CREATE TABLE AS および CREATE MATERIALIZED VIEW に対する EXPLAIN がエラーにならなく なった。 – 新機能というより bug-fix に近い気がする。

E.1.3.1.4. Optimizer ● CREATE TABLE AS の例（ PostgreSQL 13 ） EXPLAIN ANALYZE CREATE TABLE IF NOT EXISTS id_1000_t AS SELECT id, data1 FROM base WHERE id <= 1000; QUERY PLAN --------------------------------------------------------------------------------------------------------------------------- Bitmap Heap Scan on base (cost=653.40..1654.25 rows=36788 width=12) (actual time=0.062..0.556 rows=1000 loops=1) Recheck Cond: (id <= 1000) Heap Blocks: exact=6 -> Bitmap Index Scan on base_pkey (cost=0.00..644.20 rows=36788 width=0) (actual time=0.046..0.047 rows=1000 loops=1) Index Cond: (id <= 1000) Planning Time: 0.135 ms Execution Time: 1.836 ms (7 rows) EXPLAIN ANALYZE CREATE TABLE IF NOT EXISTS id_1000_t AS SELECT id, data1 FROM base WHERE id <= 1000; psql:test.sql:8: ERROR: relation "id_1000_t" already exists [ec2-user@ip-10-0-1-10 create_table_as]$

E.1.3.1.4. Optimizer ● CREATE TABLE AS の例（ PostgreSQL 14 ） EXPLAIN ANALYZE CREATE TABLE IF NOT EXISTS id_1000_t AS SELECT id, data1 FROM base WHERE id <= 1000; QUERY PLAN --------------------------------------------------------------------------------------------------------------------------- Bitmap Heap Scan on base (cost=653.40..1654.25 rows=36788 width=12) (actual time=0.060..0.549 rows=1000 loops=1) Recheck Cond: (id <= 1000) Heap Blocks: exact=6 -> Bitmap Index Scan on base_pkey (cost=0.00..644.20 rows=36788 width=0) (actual time=0.044..0.045 rows=1000 loops=1) Index Cond: (id <= 1000) Planning Time: 0.142 ms Execution Time: 1.897 ms (7 rows) EXPLAIN ANALYZE CREATE TABLE IF NOT EXISTS id_1000_t AS SELECT id, data1 FROM base WHERE id <= 1000; psql:test.sql:8: NOTICE: relation "id_1000_t" already exists, skipping QUERY PLAN ------------ (0 rows)

E.1.3.1.5. General Performance ● executor method to cache results – Nested Loop 結合の内側の結果を Executor 内にキャッシュとして保存する。デフォ ルトは on ● async_capable – ForeignScan 処理において非同期処理を実行可能になった – CREATE SERVER で外部サーバ定義時にこのオプションを on にする。 – 複数の外部テーブルを参照する問い合わせの場合、 外部テーブルスキャンを並行実行可能にする – postgres_fdw が対応している

E.1.3.1.5. General Performance ● async_capable 親テーブル 子外部テーブル 1 子外部テーブル 2 子外部テーブル 3 テーブル 1 テーブル 2 テーブル 3 ① ② ③ ④ ⑤ ⑥ 親テーブル 子外部テーブル 1 子外部テーブル 2 子外部テーブル 3 テーブル 1 テーブル 2 テーブル 3 ① ②(async) ③ ④(async) ⑤ ⑥(async) ● ①→②→③→④→⑤→⑥ のように シーケンシャルに実行される。 ● ①→②→③→④→⑤→⑥ という流れは同じだ が、② , ④, ⑥ の完了を待たずに後続の③ , ⑤ の 処理に遷移する。 async_capable=on 従来

E.1.3.1.5. General Performance ● async_capable の設定例 – postgresql.conf パラメータではなく、 CREATE SERVER コマンドのオプションとして指定する。 – PostgresQL 14 では、 postgres_fdw のみ対応している。 CREATE SERVER srv1 FOREIGN DATA WRAPPER postgres_fdw OPTIONS (port '14001', dbname 'testdb', async_capable 'on')

E.1.3.1.5. General Performance ● async_capable が off （従来のケース）の実行計画 EXPLAIN SELECT AVG(data) FROM test ; QUERY PLAN ----------------------------------------------------------------------------------- Aggregate (cost=618.00..618.01 rows=1 width=8) -> Append (cost=100.00..598.80 rows=7680 width=8) -> Foreign Scan on test1 test_1 (cost=100.00..186.80 rows=2560 width=8) -> Foreign Scan on test2 test_2 (cost=100.00..186.80 rows=2560 width=8) -> Foreign Scan on test3 test_3 (cost=100.00..186.80 rows=2560 width=8) (5 rows)

E.1.3.1.5. General Performance ● async_capable が on の実行計画 (1) EXPLAIN SELECT AVG(data) FROM test ; QUERY PLAN ----------------------------------------------------------------------------------------- Aggregate (cost=618.00..618.01 rows=1 width=8) -> Append (cost=100.00..598.80 rows=7680 width=8) -> Async Foreign Scan on test1 test_1 (cost=100.00..186.80 rows=2560 width=8) -> Async Foreign Scan on test2 test_2 (cost=100.00..186.80 rows=2560 width=8) -> Async Foreign Scan on test3 test_3 (cost=100.00..186.80 rows=2560 width=8) (5 rows)

E.1.3.1.5. General Performance ● async_capable が on の実行計画 (2) – async_capable が on でも他の GUC 設定によっては、従来の Foreign Scan になるケースもある。 SET enable_partitionwise_aggregate = on; SET EXPLAIN SELECT AVG(data) FROM test ; QUERY PLAN ----------------------------------------------------------------------------------------- Finalize Aggregate (cost=579.65..579.66 rows=1 width=8) -> Append (cost=193.20..579.64 rows=3 width=32) -> Partial Aggregate (cost=193.20..193.21 rows=1 width=32) -> Foreign Scan on test1 test (cost=100.00..186.80 rows=2560 width=8) -> Partial Aggregate (cost=193.20..193.21 rows=1 width=32) -> Foreign Scan on test2 test_1 (cost=100.00..186.80 rows=2560 width=8) -> Partial Aggregate (cost=193.20..193.21 rows=1 width=32) -> Foreign Scan on test3 test_2 (cost=100.00..186.80 rows=2560 width=8) (8 rows)

E.1.3.1.5. General Performance ● Add ability to use LZ4 compression on TOAST data. – これまで： TOAST(*1) 圧縮方式は pglz 方式固定 – PostgreSQL 14 ： lz4 方式が選択可能 – LZ4 ライブラリをインストールして、 --with-lz4 オプションつきで構築する ● PostgreSQL 14 beta3 RPM では --with-lz4 オプションつきで 構築されていた。 – default_toast_compression パラメータまたは、 ALTER TABLE で設定する (*1) The Oversized-Attribute Storage Technique

E.1.3.1.5. General Performance ● pglz vs LZ4 – LZ4 は圧縮と展開の速さに焦点を当てた可逆圧縮 – 圧縮後のサイズは LZ4 のほうが pglz よりも大きい？ ● 実際どうなのか、手元の環境で測定してみた

E.1.3.1.5. General Performance ● pglz vs LZ4 – 青空文庫の「三国志」の各章を 1 つのテキストとして扱う – COPY FROM による圧縮、サイズ、 SeqScan による展開（ 5 回測定平均） 平均 0 50 100 150 200 250 300 274.2 81.13 COPY FROM 処理時間 (ms) lz4 pglz サイズ (MB) 0 0.5 1 1.5 2 2.5 3 3.5 2.81 3.31 pg_total_relation_size(MB) lz4 pglz 平均 0 5 10 15 20 25 21.87 10.77 Seq Scan 時間 (ms) lz4 pglz ● 日本語だと lz4 との相性良いのかも。

E.1.3.1.6. Monitoring ● サーバー変数 compute_query_id の追加 – pg_stat_activity 、 EXPLAIN VERBOSE 、 csvlog 、および オプションで log_line_prefix に表示 – pg_stat_statements などの一部の拡張機能にも対応

E.1.3.1.7. System Views ● 監視用に追加されたシステムビュー システムビュー名 内容 pg_stat_progress_copy COPY の進捗を確認可能なビュー pg_stat_wal クラスタの WAL 活動に関するデータを含んでいるビュー。 pg_stat_wal ビューは常に 1 行である。 pg_stat_replication_slots ロジカルレプリケーションスロットごとに 1 行を含み、その 使用状況に関する統計を表示します。 pg_backend_memory_contexts 現在のセッションに接続されているサーバープロセスのすべ てのメモリコンテキストを表示するビュー。 ● 列が追加されたシステムビューも多い。

E.1.3.1.7. System Views ● pg_stat_progress_copy – COPY コマンドの進捗状況を確認できるビュー ● COPY FROM/COPY TO どちらの進捗状況も確認可能 ● psql の \copy コマンドも確認可能 ● 論理レプリケーションの初期同期も確認可能 – 入出力先や動作モードによって進捗状況を示す列が異なる

E.1.3.1.7. System Views ● pg_stat_progress_copy のビュー内容 列名 データ型 内容 pid integer COPY コマンドを実行中のバックエンドプロセスの PID datid oid COPY コマンドを実行中のバックエンドプロセスが接続しているデータベースの oid datname name COPY コマンドを実行中のバックエンドプロセスが接続しているデータベース名 relid oid COPY コマンドが実行されるテーブルの OID 。 SELECT クエリからコピーする場合は 0 に設定される。 command text 実行中のコマンド。（ COPY FROM/COPY TO など） type text データの読み取りまたは書き込みが行われる I/O タイプ。 FILE 、 PROGRAM 、 PIPE 、 CALLBACK の値が設定される bytes_processed bigint COPY コマンドによってすでに処理されたバイト数 bytes_total bigint COPY FROM コマンドのソースファイルのサイズ（バイト単位） tuples_processed bigint COPY コマンドによってすでに処理されたタプル数 tuples_excluded bigint COPY コマンドの WHERE 句によって除外されたために処理されなかったタプル数

E.1.3.1.7. System Views ● pg_stat_progress_copy （ copy 方式による挙動の差異） 列名 COPY TO COPY FROM COPY FROM (WHERE 句つき ) \copy TO pid 設定される 設定される 設定される 設定される datid 設定される 設定される 設定される 設定される datname 設定される 設定される 設定される 設定される relid 0 のまま 設定される 設定される 0 のまま command COPY TO COPY FROM COPY FROM COPY TO type FILE FILE FILE PIPE bytes_processed 設定される 設定される 設定される 設定される bytes_total 0 のまま 設定される 設定される 0 のまま tuples_processed 設定される 設定される 設定される 設定される tuples_excluded 0 のまま 0 のまま 設定される 0 のまま

E.1.3.1.9. Server Configuration ● idle_session_timeout – セッションの idle 状態が、この設定パラーメタを超えた場合、セッショ ンを切断する。 – デフォルト値は 0 （無効） – GUC 設定ではなく、インタラクティブなセッションにログインする ユーザの ALTER TABLE 設定として使うのが良さそう？ – PostgreSQL 9.6 で追加された、 idle_in_transaction_timeout に似ている。

E.1.3.1.9. Server Configuration ● idle_session_timeout の例 $ ~/pgsql/pgsql-14b3/bin/psql -p 10014 -U postgres postgres -e -f timeout-test.sql SET idle_session_timeout = 1000; SET SELECT now(); now ------------------------------- 2021-09-08 11:14:03.700523+09 (1 row) SELECT pg_sleep(3); pg_sleep ---------- (1 row) SELECT now(); now ------------------------------- 2021-09-08 11:14:06.704037+09 (1 row) これはクエリ実行中なので、 idle_session_timeout を超えてもセッションは中断されない。

E.1.3.1.9. Server Configuration ● idle_session_timeout の例（つづき） Wed 08 Sep 2021 11:14:06 AM JST (every 3s) now ------------------------------- 2021-09-08 11:14:06.704349+09 (1 row) psql:timeout-test.sql:5: FATAL: terminating connection due to idle-session timeout server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. psql:timeout-test.sql:5: fatal: connection to server was lost [ec2-user@ip-10-0-1-10 idle-session-timeout]$ psql の \watch によって 3 秒待つ。 idle 状態が 3 秒以上になるので idle-session timeout となり セッションが切断される

E.1.3.2. Streaming Replication and Recovery ● pg_rewind をスタンバイサーバを使って巻き戻し可能になった – pg_rewind はタイムライン分岐後の別のデータベースクラス タと同期するユーティリティ – 以前はスタンバイサーバに対して pg_rewind は使用不可

E.1.3.2. Streaming Replication and Recovery ● restore_command の設定をサーバのリロード中に変更可能になった。 – PostgreSQL 11 以前は recovery.conf で設定 – PostgreSQL 12,13 では postgresql.conf で設定。 PostgreSQL サーバの再起動が必要だった。 – 「 restore_command を空の文字列に設定してリロードすることで強 制的に pg_wal ディレクトリからのみ読み取らせる」 という使い方の例があったが、実運用でどう使うのかは自分にはまだ 理解できていない・・・

E.1.3.2.1. Logical Replication ● 進行中の長いトランザクションをサブスクライバにストリームで きるようになった。 – これまでは、 logical_decoding_work_mem を超えたトラン ザクションは、トランザクションが完了するまでディスクに書 き込まれていた。 ● 論理デコードの API を強化し、 2 フェーズコミットを扱えるよう にした。

E.1.3.3. SELECT, INSERT ● AS なしでは列ラベルにできないキーワード制限の改善 (90% 改善 ) – 以下のキーワードで挙動を確かめてみた。 キーワード PostgreSQL 14 PostgreSQL 13 SELECT × × ORDER × × INSERT ○ × UPDATE ○ × DELETE ○ × CREATE × × DROP ○ × ALTER ○ × できるからと言って そういう混乱しそうな SQL は書かないほうが 良いとは思うけど testdb=# SELECT id, data UPDATE FROM test.foo ; id | update ----+-------- (0 rows) testdb=#

E.1.3.3. SELECT, INSERT ● JOIN の USING 句にエイリアスを指定できるようになった testdb=# SELECT aid, b.bid FROM pgbench_accounts JOIN pgbench_branches USING (bid) AS b WHERE b.bid = 1 ; ERROR: syntax error at or near "AS" LINE 3: USING (bid) AS b ^ testdb=# testdb=# SELECT aid, b.bid FROM pgbench_accounts JOIN pgbench_branches USING (bid) AS b WHERE b.bid = 1 ; aid | bid --------+----- 14702 | 1 6894 | 1 6895 | 1 ● PostgreSQL 13 ● PostgreSQL 14

E.1.3.4. Utility Commands ● REFRESH MATERIALIZED VIEW 操作を並列化 ● REINDEX 時にテーブル空間変更可能 ● TRUNCATE で外部テーブルを空化可能 (postgres_fdw)

E.1.3.4. Utility Commands ● REFRESH MATERIALIZED VIEW 操作を並列化 – EXPLAIN では REFRESH MATERIALIZED VIEW は確認できない – pg_stat_activity を参照すると backend_type が” parallel worker” の 行が報告される SELECT query_start, query, backend_type FROM pg_stat_activity WHERE backend_type = 'parallel worker'; query_start | query | backend_type -------------------------------+----------------------------------------+----------------- 2021-09-10 06:57:54.337539+09 | REFRESH MATERIALIZED VIEW base_avg_mv; | parallel worker 2021-09-10 06:57:54.337539+09 | REFRESH MATERIALIZED VIEW base_avg_mv; | parallel worker (2 rows)

E.1.3.4. Utility Commands ● REINDEX 時にテーブル空間変更可能になった – 以前は ALTER INDEX コマンドのみ変更可能 REINDEX [ ( option [, ...] ) ] { INDEX | TABLE | SCHEMA | DATABASE | SYSTEM } [ CONCURRENTLY ] name where option can be one of: CONCURRENTLY [ boolean ] TABLESPACE new_tablespace VERBOSE [ boolean ]

E.1.3.4. Utility Commands ● REINDEX 時にテーブル空間を変更する例 testdb=# SELECT DISTINCT c.relname, c.relkind, ts.spcname FROM pg_class c JOIN pg_namespace ns ON (c.relnamespace = ns.oid) JOIN pg_tablespace ts ON (ts.oid = c.reltablespace) WHERE ns.nspname = 'my_schema'; relname | relkind | spcname ---------+---------+--------- (0 rows) testdb=# REINDEX (TABLESPACE my_tblspc) INDEX my_schema.test_id_idx; REINDEX testdb=# SELECT DISTINCT c.relname, c.relkind, ts.spcname FROM pg_class c JOIN pg_namespace ns ON (c.relnamespace = ns.oid) JOIN pg_tablespace ts ON (ts.oid = c.reltablespace) WHERE ns.nspname = 'my_schema'; relname | relkind | spcname -------------+---------+----------- test_id_idx | i | my_tblspc (1 row)

E.1.3.4. Utility Commands ● TRUNCATE で外部テーブルを空化可能 (postgres_fdw) testdb=# \d List of relations Schema | Name | Type | Owner --------+-------+-------------------+---------- public | test | partitioned table | postgres public | test1 | foreign table | postgres public | test2 | foreign table | postgres public | test3 | foreign table | postgres (4 rows) testdb=# SELECT COUNT(*) FROM test; count --------- 1000000 (1 row) testdb=# TRUNCATE test; TRUNCATE TABLE testdb=# SELECT COUNT(*) FROM test; count ------- 0 (1 row) ● 親テーブル→子外部テーブル→リモー トテーブルを TRUNCATE できるよう になった ● postgresql_fdw ＋パーティション構 成を組んでいる場合、 （地味だけど）嬉しい機能になりそう

E.1.3.5. Data Types ● マルチレンジ型 – 複数の重なりのない範囲を 1 つの型で指定可能になった。 – TYPEmultirange() 生成関数で複数範囲を指定 ● TYPE は int4, int8, num, ts, tstz, date を指す

E.1.3.5. Data Types ● マルチレンジ型の使用例 (1) CREATE TABLE rooms (no text primary key, reserved datemultirange); CREATE TABLE Table "public.rooms" Column | Type | Collation | Nullable | Default ----------+----------------+-----------+----------+--------- no | text | | not null | reserved | datemultirange | | | Indexes: "rooms_pkey" PRIMARY KEY, btree (no) INSERT INTO rooms VALUES ('101', datemultirange( daterange('2021-09-01', '2021-09-02', '[]'), daterange('2021-09-07', '2021-09-09')) ), ('201', datemultirange( daterange('2021-09-03', '2021-09-05', '[]')) ) ; INSERT 0 2 daterange() は 従来の範囲型生成関数

E.1.3.5. Data Types ● マルチレンジ型の使用例 (2) TABLE rooms; no | reserved -----+--------------------------------------------------- 101 | {[2021-09-01,2021-09-03),[2021-09-07,2021-09-09)} 201 | {[2021-09-03,2021-09-06)} (2 rows) SELECT * FROM rooms WHERE NOT( reserved && daterange('2021-09-05', '2021-09-06', '[]') ); no | reserved -----+--------------------------------------------------- 101 | {[2021-09-01,2021-09-03),[2021-09-07,2021-09-09)} (1 row) SELECT * FROM rooms WHERE NOT( reserved && daterange('2021-09-05', '2021-09-07', '[]') ); no | reserved ----+---------- (0 rows) 9/5 ～ 9/6 の空き部屋は？ 9/5 ～ 9/7 の空き部屋は？

E.1.3.6. Functions ● SQL 言語の関数やプロシージャで、 SQL 標準のファンクション ボディを使用可能になった。 – これまでは、単一引用符または $$ 引用符で囲まれた関数本体 の記述のみ対応していた。

E.1.3.7. PL/pgSQL ● plpgsql の RETURN QUERY がパラレルクエリを実行可能 – 既存の PL/pgSQL を修正しなくても、性能改善が見込める。

E.1.3.8. Client Interfaces ● libpq にパイプラインモードを追加 – 複数のクエリを送信し、特定の同期メッセージが送信されたと きにのみ完了を待つ

E.1.3.8. Client Interfaces ● libpq の接続文字列の target_session_attrs パラメーターオプ ションを拡張 設定値 対応バージョン 意味 any PostgreSQL 10 ～ 制限なし read-write PostgreSQL 13 ～ 読み書き可能なトランザクションのみ受け付ける read-only PostgreSQL 14 ～ 読み書き可能なトランザクションを受け入れない primary PostgreSQL 14 ～ サーバーがホットスタンバイモードになっていないこと standby PostgreSQL 14 ～ サーバーがホットスタンバイモードであること prefer-standby PostgreSQL 14 ～ 最初にスタンバイ・サーバの検索を試みて、全てのホス トがスタンバイ・サーバではない場合、 any モードで 再試行する

E.1.3.9. Client Applications ● vacuumdb のオプション追加 – --no-index-cleanup ：デッドタプルを指すインデックスエン トリを削除しないオプション – --no-truncate ：テーブル末端の空ページを切り捨てないよう にするオプション ● 複数の詳細オプションの指定（ -v ）を許可 – pg_dump, pg_dumpall, and pg_restore

E.1.3.9.1. psql ● psql メタコマンドに関する改善 – \df,\do の改善 – \d[i|m|t]+ の改善 – \dt,\di の改善 – \dX の追加 – \dT の改善 – \e の改善 ● \connect 改善（謎）： beta1 時に検証したが改善内容が理解できず・・・ ● TAB 保管

E.1.3.9.1. psql ● \d[i|m|t]+ の改善 testdb=# \d+ bar Table "public.bar" Column | Type | Collation | Nullable | Default | Storage | Compression | Stats target | Description --------+---------+-----------+----------+---------+----------+-------------+--------------+------------- id | integer | | | | plain | | | data1 | text | | | | extended | pglz | | data2 | text | | | | extended | lz4 | | Access method: heap pglz or lz4 が表示される。 デフォルトは pglz testdb=# CREATE TABLE foo (id int, data text, ts timestamp); CREATE TABLE testdb=# CREATE INDEX foo_id_idx ON foo (id); CREATE INDEX testdb=# CREATE INDEX foo_ts_idx ON foo USING brin(ts); CREATE INDEX testdb=# \di+ List of relations Schema | Name | Type | Owner | Table | Persistence | Access method | Size | Description --------+------------+-------+----------+-------+-------------+---------------+------------+------------- public | foo_id_idx | index | postgres | foo | permanent | btree | 8192 bytes | public | foo_ts_idx | index | postgres | foo | permanent | brin | 48 kB | (2 rows) テーブルやインデックスの アクセスメソッド列の追加

E.1.3.9.1. psql ● TAB 保管 ● PostgreSQL 13 testdb=# TRUNCATE T testdb=# TRUNCATE TABLE foo information_schema. pg_catalog. pg_toast. public. testdb=# TRUNCATE TABLE foo testdb=# TRUNCATE TABLE foo $ ~/pgsql/pgsql-14b1/bin/psql -p 10014 -U postgres testdb psql (14beta1) Type "help" for help. testdb=# TRUNCATE T ● PostgreSQL 14 “T” の後には何も補完されない。 テーブル名の後には何も補完されない。 ここでタブをおすと・・・ testdb=# TRUNCATE TABLE テーブル名の後にも補完してくれる・・・ testdb=# TRUNCATE TABLE foo CASCADE CONTINUE IDENTITY RESTART IDENTITY RESTRICT

E.1.3.10. Server Applications ● コマンドラインユーティリティ pg_amcheck の追加 ● initdb に --no-instructions オプションの追加 – PostgreSQL 起動例の出力抑止 ● pg_upgrade の analyze_new_cluster スクリプト作成を停止 – 同等の vacuumdb の実行方法を出力する

E.1.3.12. Source Code ● configure オプションの変更 – --with-ssl={openssl} の追加 ● 以前の --with-openssl も互換性のために残してある – --with-lz4 ● このオプションを付けてビルドをしないと、 TOAST 時の lz4 圧縮方式指定ができなくなる

E.1.3.13. Additional Modules ● 行の可視性を変更できる contrib モジュール pg_surgery を追加 – データベースの破損の修正時に使うものらしい・・・ ● pageinspect の改善 – GiST インデックスを検査可能になった – ブロック番号を bigint に変更

E.1.3.13.1. pg_stat_statements ● pg_stat_statements ビューの列追加 ● pg_stat_statements_info システムビューの追加 testdb=# CREATE EXTENSION pg_stat_statements ; CREATE EXTENSION testdb=# \d List of relations Schema | Name | Type | Owner --------+-------------------------+-------+---------- public | pg_stat_statements | view | postgres public | pg_stat_statements_info | view | postgres public | pgbench_accounts | table | postgres public | pgbench_branches | table | postgres public | pgbench_history | table | postgres public | pgbench_tellers | table | postgres (6 rows)

E.1.3.13.1. pg_stat_statements ● pg_stat_statements_info システムビューの追加 testdb=# TABLE pg_stat_statements_info ; dealloc | stats_reset ---------+------------------------------- 0 | 2021-09-11 14:30:22.914704+09 (1 row) 列名 データ型 内容 dealloc bigint pg_stat_statements.max より多くのクエリを記録しようとし て、 pg_stat_statements エントリが解放された回数 stats_reset timestamptz pg_stat_statements ビューのすべての統計情報が最後にリセットされた時間

E.1.3.13.2. postgres_fdw ● postgres_fdw が行を一括で挿入可能 – postgres_fdw 構成環境でのデータロード高速化 ● postgres_fdw がテーブルパーティションをインポート可能 – IMPORT FOREIGN SCHEMA ... LIMIT TO で指定 ● 必要に応じて postgres_fdw が外部サーバー接続を再確立する – 外部サーバの再起動後のエラー抑止

互換性に関する注意 ● PostgreSQL 14 の非互換性項目は結構多い（ 27 項目） ● 注意が必要そうなもの – サーバ変数 password_encryption のデフォルトが md5 から scram-sha- 256 に変更 ● pg_hba.conf の method が md5 のままだとハマるかも。 – サーバ変数 vacuum_cleanup_index_scale_factor を削除 – サーバ変数 operator_precedence_warning を削除 – contrib/pg_standby ユーティリティの削除

もうすぐリリースです！ ● 派手な機能追加等はないけど、色々使いやすく改善された版。 ● 互換性に関する注意点は多いので移行前に確認を。 ● Release Candidate 版ももうすぐリリースされるので、ダウン ロードしてお試しも可能です。 14.0 リリースは 2021-09-30 （たぶん）

おわり