search
LoginSignup
1

More than 1 year has passed since last update.

posted at

PostgreSQL 13がやってくる!(2) - システムカタログの差分を調べてみる

はじめに

今回は、PostgreSQL 12とPostgreSQL 13のシステムカタログの差分を調べてみる。
これもまだβ版リリース前なので、今後変わっていく可能性が大きいけど、現時点の版で調査をしてみた。
普段、PostgreSQLを使っているときにはシステムカタログを意識することはそれほどないのだが、システムカタログの変更は、DDL系コマンドや監視用の活動統計ビューの変更にも密接に関連しているので、調べてみるといろいろなことが分かって面白い。

調査方法

PostgreSQL 12とPostgreSQL 13-devel1それぞれについて、initdbによるデータベースクラスタ生成直後に、postgresデータベースにpsqlでログインして、psqlのメタコマンド

\d pg_catalog.*

を実行し、そのログをdiffで比較した。

テーブル/ビュー単位での変更まとめ

今回は、PostgreSQL 12のときほど大きな変更はない印象。

リレーション名 kind 変更種別 その他修正
pg_available_extension_versions ビュー 変更 trusted 列の追加
pg_pltemplate 削除
pg_shmem_allocations ビュー 追加
pg_stat_activity ビュー 変更 leader_pid 列の追加
pg_stat_progress_analyze ビュー 追加
pg_stat_progress_basebackup ビュー 追加
pg_stat_replication ビュー 変更 spill_txns, spill_count, spill_bytes列の追加
pg_statistic_ext 変更 stxstattarget列の追加
pg_trigger 変更 tgparentid列の追加

\dコマンドだと、表に設定されたインデックスの表示順番は一定にならないのが嫌らしい・・・(pg_constraint, pg_inherits, pg_triggerは、そのためにdiff取ると差分があるように見えてしまう・・・)

pg_pltemplate

削除された。この改修による影響らしい。
Remove pg_pltemplate, add trustable extensions instead

pg_shmem_allocations

なんと、このシステムビュー、2014年の頃に最初の議論が始まっていた。6年越しにコミットされた機能のようだ。
この機能に関するMLの議論

システムビュー自体の説明はpg_shmem_allocationsにある。
共有メモリの割当状況を表示するものらしい。

postgres=# TABLE pg_shmem_allocations ;
                name                 |    off    |   size    | allocated_size
-------------------------------------+-----------+-----------+----------------
 Buffer IO Locks                     | 140660480 |    524288 |         524288
 Buffer Descriptors                  |   5394176 |   1048576 |        1048576
 Async Queue Control                 | 147076480 |      2492 |           2560
 Wal Sender Ctl                      | 147069824 |      1360 |           1408
 AutoVacuum Data                     | 147061376 |      5368 |           5376
 commit_timestamp                    |   4791552 |    133600 |         133632
 multixact_member                    |   5259392 |    133600 |         133632
・・・

pg_stat_progress_analyze

ANALYZE処理の進捗状況を示すビューですね。

ANALYZEの処理も、対象となるテーブルやデータベースが巨大な場合には、それなりに時間のかかるもの。(去年、とあるTBオーダーの移行案件を対応したときに、ロード後のANALYZEがなかなか終わらなくて(お腹も空いていたので)、にゃーんと思っていたときに、この機能があれば、あとどのくらいで終わりそうか推測できたかもしれないな・・・と思い出したり)。

この機能に関する議論→progress report for ANALYZE

ANALYZEに関する進捗を示すシステムビューの内容はANALYZE Progress Reportingを参照。

pg_stat_progress_basebackup

これは、pg_basebackupの進捗状況を示すビューを提供するもののようですね。
この機能に関する議論→pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side

提供されるビューの内容については、Base Backup Progress Reportingを参照。
従来の--progress オプションとの違いが気になるところ。

大きめのデータベースクラスタを作ってあとで確認しなくては。

列単位での変更内容

pg_stat_activity

この機能に関する議論→Expose lock group leader pid in pg_stat_activity

追加された列に関する説明はpg_stat_activity Viewを参照。
今回はleader_pidという列が追加されている。

leader_pid is 何?

すごく雑にいうと、パラレルクエリが動作している場合、ワーカープロセスを束ねるpidが表示されるっぽい。

例えば非常にシンプルなパラレルクエリが動くケース(pgbenchでscale factor=10で、ロードして、SELECT pg_sleep(10), COUNT(*) FROM pgbench_accounts)を実行すると、一瞬(パラレルワーカプロセスが動いているときに)、pg_stat_actuvityを検索すると、以下のような結果が取得される。

  pid  | leader_pid |         backend_type
-------+------------+------------------------------
 17652 |            | autovacuum launcher
 17654 |            | logical replication launcher
 17906 |      17906 | client backend
 17941 |            | client backend
 17994 |      17906 | parallel worker
 17995 |      17906 | parallel worker
 17650 |            | background writer
 17649 |            | checkpointer
 17651 |            | walwriter
(9 rows)

backend_typeparallel workerのleader_pidがワーカー起動元になった、client backendの17906になっていることがわかる。

pg_stat_replication

論理レプリケーションに関連する情報、spill_txns, spill_count, spill_bytes列が追加された。

列名 内容
spill_txns 論理デコードで使用されるメモリがlogical_decoding_work_memを超えた後にディスクに書き出されたトランザクションの数。
spill_count トランザクションがディスクに流出した回数。 トランザクションは繰り返し書き出される可能性があり、このカウンタはそのような呼び出しごとに増分されます。
spill_bytes デコードされたトランザクションデータのディスクへの書き出し量。

pg_statistic_ext

stxstattarget列が追加された。

列名 内容
stxstattarget (まだPostgreSQL Documentに反映されてない・・・)

pg_trigger

パーティションに関連するtgparentid列が追加された。

列名 内容
tgparentid このトリガーのクローン元の親トリガー。クローンでない場合はゼロ。 これは、パーティションが作成されるか、パーティションテーブルにアタッチされるときに発生します。

おわりに

今後、新たな機能がcommitされれば差分もまた増えていくと思うので、これも今後開発フェーズが進んだら、また再調査しておきたい。


  1. 今回調査対象としたのは、3/13時点の版(commit dbf95c843a3d66cf9a692f5937a1bec4f2261035)。 

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
1