PostgreSQL 14 is coming

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.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 • 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_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 （たぶん）

おわり

PostgreSQL 14 is coming

PostgreSQL 14 is coming

More Decks by nuko_yokohama

Other Decks in Technology

Featured

Transcript