PostgreSQL にデータをリストアした後に行う ANALYZE について(2)

本記事の概要

PostgreSQL 18 の新機能として「統計情報が論理バックアップ（ダンプファイル）に含まれる」ようになりました。
本記事では、この機能について確認した内容を紹介します。

※ 以前に PostgreSQL 12.7 で確認した内容は下記となります。
https://www.insight-ltd.co.jp/tech_blog/postgresql/520/

プランナ統計情報

PostgreSQL において統計情報と呼ばれるものはいくつかの種類がありますが、今回の新機能の対象となるのは「プランナ統計情報」と呼ばれるものです。

プランナ統計情報は、ANALYZE が実行された際に収集され、pg_class や pg_statistic に格納されます。これは、効率的な実行計画を作成するために使用される重要な情報となります。

PostgreSQL 17 以前では、論理バックアップをリストアした後、ANALYZE を行うのが一般的な運用方法でした。
今回の機能追加により、運用方法を変更する必要があるのかを確認しました。

実際に確認

実際に pg_dump を実行して検証を行いました。
検証の方法は、下記の 2 パターンを行いました。

1. PostgreSQL 17 と 18 で出力した pg_dump を比較
2. PostgreSQL 18 でオプションを変えて出力した pg_dump を比較

検証した環境

実際に検証に利用した環境は下記となります。

• RockyLinux 9.6
• PostgreSQL 17.6
• PostgreSQL 18.0

1. PostgreSQL 17 と 18 で出力した pg_dump を比較

まず、PostgreSQL 17 と 18 で pg_dump を実行し、出力された論理バックアップを比較して、変更点を確認しました。
検証用のデータベースは、pgbench コマンドを利用して用意しました。
具体的には

pgbench -i -s 1

というコマンドを PostgreSQL 17 と 18 で実行し、それぞれのデータベースに対してオプションなしの pg_dump コマンドを実行し、論理バックアップを取得しました。

比較結果

PostgreSQL 17 と 18 で取得した論理バックアップを diff コマンドで比較した結果が下記となります。

5c5
< \restrict f2dBBCp7zbKcyo3Tmatf2SNpbDZFgtnZWSNp9HdCDRteaqBTZ5l9FSZ3It6od1V
---
> \restrict jIX85UuipxJ8rwYsxgKSKP4NumVMznjpOhqXWjz2oF51OGV8tbyYv7m7tiPZdPQ
7,8c7,8
< -- Dumped from database version 17.6
< -- Dumped by pg_dump version 17.6
---
> -- Dumped from database version 18.0
> -- Dumped by pg_dump version 18.0
100157c100157
< \unrestrict f2dBBCp7zbKcyo3Tmatf2SNpbDZFgtnZWSNp9HdCDRteaqBTZ5l9FSZ3It6od1V
---
> \unrestrict jIX85UuipxJ8rwYsxgKSKP4NumVMznjpOhqXWjz2oF51OGV8tbyYv7m7tiPZdPQ

上記の通り、PostgreSQL 17 と 18 で、特別に変動されている点はないようです。
pg_dump のオプションなし（デフォルト）では、統計情報が含まれないことを確認できました。

公式ドキュメントを確認

裏付けとして公式ドキュメント（英語）を確認しますと、プランナ統計情報を含むためのオプションとして、--statistics と --statistics-only が追加されていました。
以下が該当の URL です。
https://www.postgresql.org/docs/18/app-pgdump.html

ちなみにプランナ統計情報を含まない --no-statistics オプションもあります。
その説明に

Do not dump statistics. This is the default.

とあるように、プランナ統計情報を含まないのがデフォルトの挙動であることを確認できました。

2. PostgreSQL 18 でオプションを変えて出力した pg_dump を比較

次に、PostgreSQL 18 で、オプションなしの pg_dump と --statistics オプションをつけた pg_dump を実行し、出力された論理バックアップを diff コマンドで比較しました。

比較結果

結果の一部を抜粋して下記に記載します。

5c5
< \restrict g2SMJznJoYeGH3cLb00kzXX3IefTxaWeTIayv5CizeERa4Gc8u9hpBxUKgoxcMC
---
> \restrict 1AHemZnljxe53nomZhkDwOaw6fuBOd8I7F7rp2ftHF3kAwEd3Yhc0h4WmUCHrtx
100129a100130,100318
> -- Statistics for Name: pgbench_accounts; Type: STATISTICS DATA; Schema: public; Owner: -
> --
> 
> SELECT * FROM pg_catalog.pg_restore_relation_stats(
>   'version', '180000'::integer,
>   'schemaname', 'public',
>   'relname', 'pgbench_accounts',
>   'relpages', '1640'::integer,
>   'reltuples', '100000'::real,
>   'relallvisible', '1640'::integer,
>   'relallfrozen', '1640'::integer
> );
> SELECT * FROM pg_catalog.pg_restore_attribute_stats(
>   'version', '180000'::integer,
>   'schemaname', 'public',
>   'relname', 'pgbench_accounts',
>   'attname', 'abalance',
>   'inherited', 'f'::boolean,
>   'null_frac', '0'::real,
>   'avg_width', '4'::integer,
>   'n_distinct', '1'::real,
>   'most_common_vals', '{0}'::text,
>   'most_common_freqs', '{1}'::real[],
>   'correlation', '1'::real
> );

差分として pg_catalog.pg_restore_relation_stats 関数および pg_restore_attribute_stats 関数を実行する SELECT 文が出力されました。
この二つの関数でプランナ統計情報を復元しているようです。

ソースコードのコメント確認

実際に pg_restore_attribute_stats 関数のコメントに pg_statistic テーブルへ値を挿入する旨の説明があります。
src/backend/statistics/attribute_stats.c より該当部分を下記に抜粋します。

• Import statistics for a given relation attribute.
• Inserts or replaces a row in pg_statistic for the given relation and
• attribute name or number. It takes input parameters that correspond to
• columns in the view pg_stats.

論理バックアップのリストア後の ANALYZE について

前述の通り、PostgreSQL 18 でも、デフォルト（オプションなし）では pg_dump で出力される論理バックアップにはプランナ統計情報は含まれません。
そのため、論理バックアップのリストア後に ANALYZE （できれば VACUUM も）を行うことが推奨となります。
その ANALYZE を省略したい場合には、pg_dump に --statistics オプションをつけて実行するように変更する必要があります。

まとめ

• PostgreSQL 18 では、論理バックアップにプランナ統計情報を含めるオプションが追加
• デフォルトでは従来通り含まれないため、リストア後に ANALYZE の実行が推奨
• --statistics オプションを利用すれば統計情報を含めることができる。
  ということを確認できました。

つまり、pg_dump の内容に関して（確認した限りでは）変動がないため、リストアなどの運用方法も変更する必要はないことを確認できました。