Upgrade to Pro — share decks privately, control downloads, hide ads and more …

PostgreSQL 14 is coming

18749909c147a9ee98f6b112911943cc?s=47 nuko_yokohama
September 17, 2021

PostgreSQL 14 is coming

This section introduces the changing features of PostgreSQL 14.
This document is the presentation slides of OSC Hiroshima 2021.

18749909c147a9ee98f6b112911943cc?s=128

nuko_yokohama

September 17, 2021
Tweet

Transcript

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

  2. 自己紹介 • ぬこ@横浜 (@nuko_yokohama) • にゃーん • 趣味でポスグレをやってる者だ • 今日は

    JPUG の人として発表します
  3. PostgreSQL のこれまで

  4. PostgreSQL とは何か ? • オープンソース ORDBMS • 20 年以上の歴史 •

    日本国内でも広く使われている • 今でも絶賛開発中 – 年に 1 回のメジャーバージョンアップ – 3 ヶ月に 1 回のマイナーバージョンアップ
  5. 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-?? ???
  6. 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 )←予定では
  7. PostgreSQL 14 新機能

  8. 修正概要 • リリースノートに書かれている修正項目は 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 今日は一部だけ 紹介します
  9. E.1.3.1. Server • 以下の定義済みロールが追加された – pg_read_all_data • 全てのスキーマへの USAGE •

    テーブル等への SELECT – pg_write_all_data • 全てのスキーマへの USAGE • テーブル等への INSERT/UPDATE/DELETE – pg_database_owner • 全てのデータベース所有者は暗黙のうちにこのロールに含まれる
  10. 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) の挙動が実に 面白い・・・ ( バグじゃない )
  11. E.1.3.1.1. Vacuuming • 削除可能なインデックスエントリの数が重要でない場合に、バキューム がインデックスのバキューム処理をスキップできるようになった – INDEX_CLEANUP オプションの dafalut=auto になり自動で上記

    の最適化を実施する • 多数のリレーションを持つデータベースのバキューム処理を高速化した
  12. E.1.3.1.2. Partitioning • パーティションテーブルの更新 / 削除のパフォーマンスを改善 • ノンブロッキングでパーティションを切り離し可能になった

  13. E.1.3.1.4. Optimizer • Optimizer 改善については、まだ自分もきちんと理解できない項 目もあって検証できていないものもあります・・・。 • IF NOT EXISTS

    つきの CREATE TABLE AS および CREATE MATERIALIZED VIEW に対する EXPLAIN がエラーにならなく なった。 – 新機能というより bug-fix に近い気がする。
  14. 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]$
  15. 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)
  16. E.1.3.1.5. General Performance • executor method to cache results –

    Nested Loop 結合の内側の結果を Executor 内にキャッシュとして保存する。デフォ ルトは on • async_capable – ForeignScan 処理において非同期処理を実行可能になった – CREATE SERVER で外部サーバ定義時にこのオプションを on にする。 – 複数の外部テーブルを参照する問い合わせの場合、 外部テーブルスキャンを並行実行可能にする – postgres_fdw が対応している
  17. 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 従来
  18. 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')
  19. 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)
  20. 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)
  21. 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)
  22. 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
  23. E.1.3.1.5. General Performance • pglz vs LZ4 – LZ4 は圧縮と展開の速さに焦点を当てた可逆圧縮

    – 圧縮後のサイズは LZ4 のほうが pglz よりも大きい? • 実際どうなのか、手元の環境で測定してみた
  24. 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 との相性良いのかも。
  25. E.1.3.1.6. Monitoring • サーバー変数 compute_query_id の追加 – pg_stat_activity 、 EXPLAIN

    VERBOSE 、 csvlog 、および オプションで log_line_prefix に表示 – pg_stat_statements などの一部の拡張機能にも対応
  26. 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 現在のセッションに接続されているサーバープロセスのすべ てのメモリコンテキストを表示するビュー。 • 列が追加されたシステムビューも多い。
  27. E.1.3.1.7. System Views • pg_stat_progress_copy – COPY コマンドの進捗状況を確認できるビュー • COPY

    FROM/COPY TO どちらの進捗状況も確認可能 • psql の \copy コマンドも確認可能 • 論理レプリケーションの初期同期も確認可能 – 入出力先や動作モードによって進捗状況を示す列が異なる
  28. 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 句によって除外されたために処理されなかったタプル数
  29. 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 のまま
  30. E.1.3.1.9. Server Configuration • idle_session_timeout – セッションの idle 状態が、この設定パラーメタを超えた場合、セッショ ンを切断する。

    – デフォルト値は 0 (無効) – GUC 設定ではなく、インタラクティブなセッションにログインする ユーザの ALTER TABLE 設定として使うのが良さそう? – PostgreSQL 9.6 で追加された、 idle_in_transaction_timeout に似ている。
  31. 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 を超えてもセッションは中断されない。
  32. 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 となり セッションが切断される
  33. E.1.3.2. Streaming Replication and Recovery • pg_rewind をスタンバイサーバを使って巻き戻し可能になった – pg_rewind

    はタイムライン分岐後の別のデータベースクラス タと同期するユーティリティ – 以前はスタンバイサーバに対して pg_rewind は使用不可
  34. E.1.3.2. Streaming Replication and Recovery • restore_command の設定をサーバのリロード中に変更可能になった。 – PostgreSQL

    11 以前は recovery.conf で設定 – PostgreSQL 12,13 では postgresql.conf で設定。 PostgreSQL サーバの再起動が必要だった。 – 「 restore_command を空の文字列に設定してリロードすることで強 制的に pg_wal ディレクトリからのみ読み取らせる」 という使い方の例があったが、実運用でどう使うのかは自分にはまだ 理解できていない・・・
  35. E.1.3.2.1. Logical Replication • 進行中の長いトランザクションをサブスクライバにストリームで きるようになった。 – これまでは、 logical_decoding_work_mem を超えたトラン

    ザクションは、トランザクションが完了するまでディスクに書 き込まれていた。 • 論理デコードの API を強化し、 2 フェーズコミットを扱えるよう にした。
  36. 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=#
  37. 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
  38. E.1.3.4. Utility Commands • REFRESH MATERIALIZED VIEW 操作を並列化 • REINDEX

    時にテーブル空間変更可能 • TRUNCATE で外部テーブルを空化可能 (postgres_fdw)
  39. 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)
  40. 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 ]
  41. 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)
  42. 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 +パーティション構 成を組んでいる場合、 (地味だけど)嬉しい機能になりそう
  43. E.1.3.5. Data Types • マルチレンジ型 – 複数の重なりのない範囲を 1 つの型で指定可能になった。 –

    TYPEmultirange() 生成関数で複数範囲を指定 • TYPE は int4, int8, num, ts, tstz, date を指す
  44. 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() は 従来の範囲型生成関数
  45. 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 の空き部屋は?
  46. E.1.3.6. Functions • SQL 言語の関数やプロシージャで、 SQL 標準のファンクション ボディを使用可能になった。 – これまでは、単一引用符または

    $$ 引用符で囲まれた関数本体 の記述のみ対応していた。
  47. E.1.3.7. PL/pgSQL • plpgsql の RETURN QUERY がパラレルクエリを実行可能 – 既存の

    PL/pgSQL を修正しなくても、性能改善が見込める。
  48. E.1.3.8. Client Interfaces • libpq にパイプラインモードを追加 – 複数のクエリを送信し、特定の同期メッセージが送信されたと きにのみ完了を待つ

  49. 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 モードで 再試行する
  50. E.1.3.9. Client Applications • vacuumdb のオプション追加 – --no-index-cleanup :デッドタプルを指すインデックスエン トリを削除しないオプション

    – --no-truncate :テーブル末端の空ページを切り捨てないよう にするオプション • 複数の詳細オプションの指定( -v )を許可 – pg_dump, pg_dumpall, and pg_restore
  51. E.1.3.9.1. psql • psql メタコマンドに関する改善 – \df,\do の改善 – \d[i|m|t]+

    の改善 – \dt,\di の改善 – \dX の追加 – \dT の改善 – \e の改善 • \connect 改善(謎): beta1 時に検証したが改善内容が理解できず・・・ • TAB 保管
  52. 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) テーブルやインデックスの アクセスメソッド列の追加
  53. 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
  54. E.1.3.10. Server Applications • コマンドラインユーティリティ pg_amcheck の追加 • initdb に

    --no-instructions オプションの追加 – PostgreSQL 起動例の出力抑止 • pg_upgrade の analyze_new_cluster スクリプト作成を停止 – 同等の vacuumdb の実行方法を出力する
  55. E.1.3.12. Source Code • configure オプションの変更 – --with-ssl={openssl} の追加 •

    以前の --with-openssl も互換性のために残してある – --with-lz4 • このオプションを付けてビルドをしないと、 TOAST 時の lz4 圧縮方式指定ができなくなる
  56. E.1.3.13. Additional Modules • 行の可視性を変更できる contrib モジュール pg_surgery を追加 –

    データベースの破損の修正時に使うものらしい・・・ • pageinspect の改善 – GiST インデックスを検査可能になった – ブロック番号を bigint に変更
  57. 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)
  58. 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 ビューのすべての統計情報が最後にリセットされた時間
  59. E.1.3.13.2. postgres_fdw • postgres_fdw が行を一括で挿入可能 – postgres_fdw 構成環境でのデータロード高速化 • postgres_fdw

    がテーブルパーティションをインポート可能 – IMPORT FOREIGN SCHEMA ... LIMIT TO で指定 • 必要に応じて postgres_fdw が外部サーバー接続を再確立する – 外部サーバの再起動後のエラー抑止
  60. 互換性に関する注意 • 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 ユーティリティの削除
  61. もうすぐリリースです! • 派手な機能追加等はないけど、色々使いやすく改善された版。 • 互換性に関する注意点は多いので移行前に確認を。 • Release Candidate 版ももうすぐリリースされるので、ダウン ロードしてお試しも可能です。

    14.0 リリースは 2021-09-30 (たぶん)
  62. おわり