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

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

## 調査方法
PostgreSQL 12とPostgreSQL 13-devel[^1]それぞれについて、``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](https://commitfest.postgresql.org/25/2246/)

## pg_shmem_allocations
なんと、このシステムビュー、2014年の頃に最初の議論が始まっていた。6年越しにコミットされた機能のようだ。
→[この機能に関するMLの議論](https://www.postgresql.org/message-id/20140504114417.GM12715%40awork2.anarazel.de)

システムビュー自体の説明は[pg_shmem_allocations](https://www.postgresql.org/docs/devel/view-pg-shmem-allocations.html)にある。
共有メモリの割当状況を表示するものらしい。

```sql
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](https://commitfest.postgresql.org/26/2164/)

ANALYZEに関する進捗を示すシステムビューの内容は[ANALYZE Progress Reporting](https://www.postgresql.org/docs/devel/progress-reporting.html#ANALYZE-PROGRESS-REPORTING)を参照。

## pg_stat_progress_basebackup
これは、pg_basebackupの進捗状況を示すビューを提供するもののようですね。
この機能に関する議論→[pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side](https://commitfest.postgresql.org/27/2435/)

提供されるビューの内容については、[Base Backup Progress Reporting](https://www.postgresql.org/docs/devel/progress-reporting.html#BASEBACKUP-PROGRESS-REPORTING)を参照。
従来の--progress オプションとの違いが気になるところ。

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

# 列単位での変更内容
## pg_stat_activity
この機能に関する議論→[Expose lock group leader pid in pg_stat_activity](https://commitfest.postgresql.org/27/2390/)

追加された列に関する説明は[pg_stat_activity View](https://www.postgresql.org/docs/devel/monitoring-stats.html#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を検索すると、以下のような結果が取得される。

```sql
  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_type`が`parallel 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``)。