10月は PostgreSQL 20 以降に向けた性能改善の議論が活発でした。インデックスの圧縮、高並列環境でのスケーラビリティ改善、クエリ最適化アルゴリズムなど、興味深いテーマが数多く議論されていました。

B-treeインデックスのプレフィックス圧縮

インデックスサイズの削減を目的として、B-tree インデックスに対するプレフィックス圧縮の提案がありました。

対象となるのは URL や JSON パス、逆DNS名など、多くの値が長い共通接頭辞（プレフィックス）を持つケースです。提案では、ページ単位で共通部分をまとめて保持し、各キーでは重複部分を省略することでサイズを削減します。

評価では、長い共通部分（https://www.example.com/… のようなURLの先頭部分）を持つURLデータの挿入テストでインデックスサイズが 3 分の 1 以下になったことが報告されています。一方で、B-tree 圧縮に関する SIGMOD 2024 の報告も引き合いに出され、検索時のCPUコストについて議論となりました。実際のオーバヘッドの確認や、それを削減できるケースの検討もされています。

並列ビットマップスキャンの改善

PostgreSQLでは、大量の行を検索するときに、複数のインデックス検索結果を組み合わせて対象となる行を絞り込むことがあります。この処理に使われるのがビットマップスキャン（Bitmap Scan）です。

現在のPostgreSQLでは、Bitmap Scanのうちテーブルから実際にデータを読み出す部分は並列化されていますが、インデックスを検索してビットマップを作成する部分は並列化されていません。今回、このインデックス検索も複数のプロセスで分担して実行する仕組みが提案されました。

各プロセスが並列にインデックスの一部を検索し、全ての結果が集まった後で、担当するテーブル部分の再割当てが行われ、並列にデータ読み出しを行います。 PoC としてパッチが投稿されましたが、その後も各プロセスへのメモリ割り当て方法や、B-tree 以外のインデックスの対応など、議論と開発が続いています。

スナップショットの再利用の高速化

高並列環境での性能改善として、スナップショット取得時のロックを減らす議論が進んでいます。

PostgreSQLでは、複数のトランザクションが同時に動作していても、一貫性のあるデータを参照できるようにMVCCという仕組みを採用しています。そのために使われるのがスナップショットで、ある時点でどのトランザクションの変更が見えるかを表しています。

現状では、スナップショット取得の際には内部でロックを取得するため、これが高並列環境でのボトルネックとなり、性能低下の原因となる場合があります。そこで、前回の取得以降に新たなコミットが発生していなければ、既存のスナップショットを再利用することで、ロックの取得を省略する仕組みが検討されています。

今月の議論では、スナップショットをまだ取得していない場合にも過去のスナップショットを再利用し、必要な情報はロックを使わずに更新する方法が検討されました。

OR条件をUNION ALLに展開する最適化

プランナ関連では、複数テーブルにまたがる OR 条件を UNION ALL に変換する最適化が提案されました。

複数テーブルにまたがる OR 条件（a.x = b.y OR a.x = b.z など）では、ハッシュ結合やマージ結合といった方法が使われず、性能が低下するという場合があります。これに対して、OR条件を複数の独立した検索に分解し、それらをUNION ALLで結合する形に変換する最適化の提案です。条件を分けることで、それぞれの検索に適した実行計画を選べるようになります。

提案のきっかけとなったのは、（残念ながら PostgreSQL 19 では見送りとなった）SQL/PGQ （グラフクエリ）機能です。グラフ探索の「無向エッジ」パターン検索では「A→B または B→A」といった OR 条件が現れますが、これを手動で UNION ALL で書き換えると数千倍の性能差が出た経験が元になっているようです。

書き換えの際には、重複した結果が出力されないように条件を追加する工夫も行われており、クエリ変換による最適化の面白さを感じる話題でした。

Quickselect による Top-N ソート

アルゴリズム面では、ORDER BY … LIMIT N を高速化するために Quickselect を利用する提案がありました。

ORDER BYとLIMITを組み合わせたSQLでは、全件をソートせずに、上位N件だけを効率よく取り出す処理（Top-N ソート）が重要になります。PostgreSQLでは、従来はこの処理にヒープを使った方法が使われていますが、LIMIT 値が大きい場合には効率が悪くなることがあります。

そこで提案されたのが、全体を並べ替えるのではなく、上位N件を選び出すQuickselectというアルゴリズムの利用です。まず上位N件に相当する範囲を選び出し、最後にそのN件だけをソートすることで計算量の削減を行っています。一方、メモリが不足する場合には従来のヒープソート方式に切り替えるなどの工夫も検討されています。

元々は SIMD を活用した別の研究成果（SIMDQuickHeap）を PostgreSQL に応用することを検討していたところ、Quickselect 単体でも十分な効果が期待できると判断しての提案であったようです。問題に適したアルゴリズムを選び直すという意味でも興味深い話題でした。

In-Placeメジャーバージョンアップグレード

運用面では、既存インスタンスを直接アップグレードする in-place アップグレードの提案が興味深い話題でした。

PostgreSQLのメジャーバージョンアップでは、通常pg_upgradeというツールが使われます。既存のデータを引き継ぎながら、新しいバージョンのデータベースを構築する仕組みですが、データベースインスタンスは新規に作成する必要があり、システムカタログの再作成やデータの移行には SQL 文のダンプとリストアを行うため、データベースの規模によっては時間がかかります。また、スタンバイサーバーは再構築する必要があります。

今回提案された pg_inplace_upgrade は、システムカタログを直接更新することで、既存のデータベースインスタンスをそのまま（in-placeで）アップグレード可能とするツールです。また、カタログの変更をWALに記録することで、スタンバイサーバーも作り直すことなくアップグレード可能です。

10月に PoC パッチが投稿され議論が始まりました。一方で、実装や保守の複雑化を懸念する意見もあり、活発な議論が行われています。

今回取り上げた話題は、性能改善やスケーラビリティ向上に関するものが中心となりました。特に、アルゴリズムやデータ構造、クエリ最適化に関する議論は、個々の機能だけでなく、その背景にある考え方に触れられる点も興味深く感じました。

そこで、本記事では性能問題発生時の調査に必要な情報を取得するための設定や、性能遅延時の分析に有用な拡張を紹介します。

パラメータ設定の対象メジャーバージョンはPostgreSQL 10以上としています。なお、検証例で使用しているPostgreSQLは PostgreSQL 18.6、OSはRocky Linux 9.5です。

OSについて

現在、PostgreSQLを使う時のOSの選択肢としてよくLinuxにするかWindowsにするかの選択があります。
新規構築でOS選択の自由度がある場合は、Linuxを推奨します。

主な理由は下記の三つです。

• 同一スペックのサーバであればLinuxのほうが性能がよい
• Linuxでは利用可能な拡張や周辺ツールの選択肢がWindowsより豊富である(今回紹介するpg_statsinfoもWindowsでは非対応)
• トラブル発生時の調査がLinuxの方が容易/Windowsでは困難なことが多い

Linuxでは性能面・運用面のメリットが多く、利用可能な拡張も豊富であるため、トラブル調査も進めやすくなります。

PostgreSQLログ関連パラメータ

PostgreSQLログに関してお勧めのパラメータ設定を紹介します。

ログ出力先

ログの出力先(log_destination)は、stderrがお勧めです。syslog を使う必要がある場合でも、stderrも含めて’stderr, syslog’に設定しましょう。syslog のみ設定するのは絶対に避けましょう。
stderrを含める時は、logging_collectorもonにしておく必要があります。

log_destination = 'stderr'
logging_collector = on

stderr をお勧めする理由は、archive_commandパラメータで設定したcpコマンドが実行される際の標準エラー出力もPostgreSQLログに含まれるからです。例えばコピー先のディスクの空き容量が無くcpコマンドが失敗した時のエラーメッセージが該当します。syslog の場合は、このメッセージはsyslogに出力されずに、log_destinationで設定されたファイルに出力されてしまいます。

また、syslogでは高負荷時などにPostgreSQLからのメッセージを取りこぼす可能性があるのもsyslogを避ける理由です。PostgreSQLマニュアルにも「syslogは、もし書き込みができなかったときメッセージの廃棄を選びます。」との記述があります。またsyslog側の機能としてレート制限があり、制限値以上のメッセージが到着した場合に"NNN messages lost due to rate-limiting"というメッセージでNNN行失われたことが伝えられます。高負荷時にこそPostgreSQLが出力するログを確認したいのに、syslogではメッセージが大量に出力される高負荷時にsyslog側でメッセージが省略されることが多々ありますので、syslogを使う必要がある場合は必ずstderrでもログを取得するようにしましょう。

チェックポイントの実行と自動VACUUM/ANALYZEの実行

PostgreSQLなどのデータベースでは一定間隔ごとにチェックポイントが実行されます。チェックポイントはshared_buffersで設定された共有バッファ上で変更されたがファイルシステム上のデータベースファイルにはまだ書き込まれていない、いわゆるダーティーバッファをすべてデータベースファイルに書き出すことで、チェックポイント終了時点のすべてのデータベースファイルで一貫性が取れている状態にすることが目的の処理です。
ダーティーバッファをすべてファイルに書き出す処理ですので、Disk I/Oを使用します。SQL実行などのクライアント側の処理への影響は程度の差はあれあります。SQL実行で何らかの影響を受けたかどうかの調査で、そのタイミングでチェックポイントが実行されていたかどうかを確認するために、チェックポイント実行(log_checkpoints)をPostgreSQLログに出力することは有用です。

log_checkpoints = on
# PostgreSQL 14までデフォルトoff、PostgreSQL 15からデフォルトon

自動VACUUMや自動ANALYZEの実行もチェックポイントと同様に、Disk I/Oを使用します。PostgreSQLログに出力する目的はチェックポイントと同様に、SQL実行時に自動VACUUMや自動ANALYZEが実行されていたかどうかを調査する観点もありますが、もう一つの観点としてSQLの実行計画が突然変わった時に、その直前で実行計画の策定に影響するオプティマイザ統計情報を更新する自動ANALYZEが実行されていたかどうかを確認する観点もあります。

log_autovacuum_min_duration = 0
# PostgreSQL 14までデフォルト-1(無効)、PostgreSQL 15からデフォルト10min(10分)

ロック待ち

突然SQLの実行が遅くなった時に、ロック待ちをしていたかどうかを確認したい場合があります。デフォルトではoff(無効)となっているlog_lock_waitsをon(有効)にしておくと、deadlock_timeoutで設定した時間(デフォルト1秒)ロック待ちをするとPostgreSQLログに出力されます。ただしdeadlock_timeoutの設定値が少なすぎるとマニュアルにも説明があるようにチェックの負荷がかかるため、本当にデッドロックが発生した場合に検知が遅くなるデメリットはありますが、チェックの負荷が軽減されるメリットもあるのでデフォルト(1秒)よりも長い時間、例えば5秒とか10秒とかを設定しましょう。下記例では10秒を設定しています。

log_lock_waits = on # デフォルト off
deadlock_timeout = 10s # デフォルト 1s

遅延SQL

log_min_duration_statement(デフォルト:-1(無効))に設定した時間以上実行にかかったSQLはPostgreSQLログに出力されます。
下記設定例では、10秒を設定していますので、10秒以上かかったSQLはPostgreSQLログに出力されます。

log_min_duration_statement = 10s # デフォルト-1(無効)

上記の設定をすべて実行した場合

上記の設定をすべて実行した場合、SQLの遅延が発生するとSQL文が実行時間と共にPostgreSQLログに出力されます。例えばSQL Aが11秒かかったことが分かり、その際、一緒にロック待ちのログが出ていれば、ロック待ちの影響で遅延が発生したことがわかります。
また、遅延が発生したタイミングで自動VACUUMもしくはチェックポイントが実行されていたとか、遅延が発生する直前に自動ANALYZEが実行されていたかもわかりますので、同じタイミングで実行されていた自動VACUUMやチェックポイントの可能性があるかないか、また自動ANALYZEにより実行計画を作成する元となるオプティマイザ統計情報が変更されて実行計画が変更された可能性があるかないかが判断可能となります。
しかし、SQLが遅延した場合に実際に実行計画が変化したのかどうかまではわかりません。SQLが遅延した時に実行計画の情報をPostgreSQLログに出力するauto_explainモジュールについて後で紹介します。

メモリ設定関連パラメータ

共有バッファ

PostgreSQLマニュアルには1GB以上物理メモリがあるサーバでのshared_buffersの妥当な初期値は物理メモリの25%という説明が記載されていますので、共有バッファはサーバの物理メモリの4分の1に設定しましょう。例えば、物理メモリが64GBならば16GBを設定します。下記設定例は、物理メモリが64GBの場合です。

shared_buffers = 16GB

サーバのメモリがどのように使用されるか、使用される比率について説明します。
PostgreSQLはOSのファイルシステム上にデータベースのファイルを作成しますので、PostgreSQLの共有メモリで全体の25%、OS側でファイルのキャッシュとして全体の25%、合わせると物理メモリ全体の半分(50%)がPostgreSQLのデータベースファイルで使われ、残りの半分(50%)でOS自体が使用するメモリとOSが起動するプロセス、そしてPostgreSQLのプロセスがメモリを使用します。

ワークメモリ

SQLを実行する際にソートやハッシュ検索などの処理ではPostgreSQLプロセスがwork_memで設定された値を上限としてメモリを使用しようとしますが、設定された値では足りない場合にディスクを使って読み書きをして処理をします。メモリ上の読み書きに比べてディスク上の読み書きは桁違いに遅いので、SQLの実行に影響しますので、サーバのメモリが不足しない程度にwork_memに大きな値を設定します。下記の例では、16MBを設定しています。

work_mem = 16MB

work_memで設定した値でメモリ上で処理が済んでいるかどうかを確認するには、ディスク上の処理が発生した場合にPostgreSQLログに出力するlog_temp_filesを0に設定して、SQLを実行します。ディスクを使用したら、ファイル削除時にPostgreSQLログに使用した一時ファイルが出力されます。

log_temp_files = 0 # デフォルト -1(無効)

postgresql.confで上記の設定をすると、ディスク上の処理がすべてPostgreSQLログに出てしまいますので、一時的にlog_temp_files=0に変更してpg_ctl reloadで設定を反映、ディスク上の使用有無をチェックするSQL文を実行、log_temp_files=-1に戻してpg_ctl reloadで設定を反映することで、調査期間の間だけPostgreSQLログに出力することが可能です。

また、特定のSQLを取り出してpsqlで実行可能な場合は、下記の例のようにセッション単位でlog_temp_files=0に設定してSQLを実行することも可能です。psqlの画面上に表示するためにclient_min_messagesも設定することで、LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp13483.0", size 10731520が表示されて一時ファイルが使用されていることが分かります。

db1=# SET log_temp_files = 0;
SET
db1=# SHOW log_temp_files;
log_temp_files
----------------
0
(1 row)

db1=# SET client_min_messages = log;
SET
db1=# EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM pgbench_accounts ORDER BY abalance DESC;
LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp13483.0", size 10731520
QUERY PLAN

------------------------------------------------------------------------------------------------------------------------------
----
Sort (cost=16476.32..16726.32 rows=100000 width=97) (actual time=65.871..80.323 rows=100000.00 loops=1)
Sort Key: abalance DESC
Sort Method: external merge Disk: 10480kB
Buffers: shared hit=1704, temp read=1310 written=1313
-> Seq Scan on pgbench_accounts (cost=0.00..2701.00 rows=100000 width=97) (actual time=0.022..14.887 rows=100000.00 loops
=1)
Buffers: shared hit=1701
Planning:
Buffers: shared hit=73
Planning Time: 0.571 ms
Execution Time: 89.080 ms
(10 rows)

上記のSQLで一時ファイルのDisk I/Oを使用しないwork_memの値を調べるには、実行計画でDiskが出なくなるwork_memの値を、セッション単位で一時的に必要最小限の大きな値に設定して、実行計画を表示させます。下記例では、16MBに設定した時に、external merge Diskがquicksort Memoryに変わりましたので、このSQLの実行直前にセッション単位のSET文でSET work_mem ='16MB';に設定すればメモリ上のソートで性能向上が見込めます。

db1=# SHOW work_mem;
work_mem
----------
4MB
(1 row)

db1=# SET work_mem = '16MB';
SET
db1=# EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM pgbench_accounts ORDER BY abalance DESC;
QUERY PLAN

------------------------------------------------------------------------------------------------------------------------------
----
Sort (cost=11005.82..11255.82 rows=100000 width=97) (actual time=38.479..51.692 rows=100000.00 loops=1)
Sort Key: abalance DESC
Sort Method: quicksort Memory: 14791kB
Buffers: shared hit=1701
-> Seq Scan on pgbench_accounts (cost=0.00..2701.00 rows=100000 width=97) (actual time=0.020..12.699 rows=100000.00 loops
=1)
Buffers: shared hit=1701
Planning Time: 0.084 ms
Execution Time: 56.287 ms
(8 rows)

SQL遅延時の対応について

auto_explain拡張を紹介する前に、SQLが遅延した時にどのような対応を取るのかについて説明します。

オプティマイザ統計情報の最新化と不要領域の整理

SQLの遅延が発生した時にまず実行してほしいのが、SQLの実行計画の基となっているオプティマイザ統計情報の最新化と、SQLの検索対象テーブルの不要領域の整理です。
SQLの検索対象となっているテーブル全て、特に対象テーブルのみに限定する必要が無い場合はデータベースに対してVACUUM (ANALYZE)を実行します。

下記実行例では、どのような実行状況なのかを表示するためにVERBOSEオプションを付けています。

VACUUM (ANALYZE,VERBOSE) 検索対象テーブル;

もしくは、対象データベースに接続した状態で、引数を省略するとデータベース全体に対してVACUUM (ANALYZE)が実行されます。

VACUUM (ANALYZE,VERBOSE);

上記コマンドの実行で、現在テーブルに入っているデータで実行計画を作成するベースとなるオプティマイザ統計情報を最新化するとともに、削除済みだがまだ回収されていない不要領域が回収されます。そのため、実行計画を策定するためのオプティマイザ統計情報がテーブルの最新状況を反映していない乖離した古い状態で、効率の悪い不適切な実行計画によりSQLが遅延していた場合は、統計情報が最新化された後の再実行では遅延が解消されます。

実行計画の取得

上記のVACUUM (ANALYZE)をSQLの対象テーブルすべてに対して実行しても性能が改善しない場合、例えば普段0.5秒程度で実行されているSQLが急に10秒とかかかるようになった時に取得が必要な情報がEXPLAIN (ANALYZE, BUFFERS) 遅延SQL;で出力される実行計画です。

EXPLAIN (ANALYZE, BUFFERS) 遅延SQL;

EXPLAINコマンドは引数のSQLをどのように実行するかの詳細ステップを書いた実行計画を出力するコマンドで、ANALYZEオプションは実際に実行した時間を出力、BUFFERSオプションはファイルアクセス時に共有バッファから読み込んだのかファイルから読み込んだのかの情報とアクセスしたバッファ数を出力します。

実行例を下記に示します。1回目はDB起動直後、2回目は連続して実行しました。2回の違いとして、shared read(Diskからの読み込み)がshared hit(共有バッファからの読み込み)になっていること、一度読み込まれて共有バッファからの読み込みになったので2回目の時間がPlanningもExecutionも短くなっていることが分かります。

$ psql db1
psql (18.6)
Type "help" for help.

db1=# EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM pgbench_accounts;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------
Seq Scan on pgbench_accounts (cost=0.00..2640.00 rows=100000 width=97) (actual time=2.176..28.884 rows=100000.00 loops=1)
Buffers: shared read=1640
Planning:
Buffers: shared hit=44 read=11
Planning Time: 0.846 ms
Execution Time: 33.923 ms
(6 rows)

db1=# EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM pgbench_accounts;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
Seq Scan on pgbench_accounts (cost=0.00..2640.00 rows=100000 width=97) (actual time=0.069..9.271 rows=100000.00 loops=1)
Buffers: shared hit=1640
Planning Time: 0.070 ms
Execution Time: 17.789 ms
(4 rows)

db1=#

上記の実行結果を、通常の速い時に取っておき、遅延が発生した遅い時にも取れば、実行計画そのものが変わったのか実行計画は同一なのか、遅い時はどのステップでどの程度遅くなっているのかの比較ができて、通常の速い時とどう違って遅いのかの理由が分かります。

なお、どの実行計画のどの段階でどの列の結果を出力しているのかのオプションであるVERBOSEオプションもあわせて指定すると、実行計画がどのように動作しているのか分かりやすくなります。下記実行例では、Outputの行がVERBOSEオプションによって追加された情報になります。

db1=# EXPLAIN (ANALYZE, BUFFERS, VERBOSE) SELECT * FROM pgbench_accounts;
QUERY PLAN

------------------------------------------------------------------------------------------------------------------------------
-----
Seq Scan on public.pgbench_accounts (cost=0.00..2640.00 rows=100000 width=97) (actual time=0.018..11.627 rows=100000.00 loop
s=1)
Output: aid, bid, abalance, filler
Buffers: shared hit=1640
Planning:
Buffers: shared hit=60
Planning Time: 1.456 ms
Execution Time: 19.776 ms
(7 rows)

db1=#

拡張(EXTENSION)

PostgreSQLの⼤きな特徴として、様々な機能を追加できる拡張(EXTENSION)があります。
ここでは性能問題の調査や分析に役立つ代表的な拡張を紹介します。

拡張を使用するためには、拡張が入ったパッケージをPostgreSQLインストール時にあらかじめインストールしておき、CREATE EXTENSIONやshared_preload_libraries変更などの設定が必要ですが、そもそも拡張をインストールしていない場合は、拡張を使用する設定をする前に後から追加でインストールが必要となります。
しかし、既にシステムが本番稼働をした状況で、後から拡張をインストールをするのはハードルが高いので、後から使いたい時に使えるよう、PostgreSQLインストール時に一緒にインストールしておくのが望ましいです。

拡張の種類

PostgreSQL本体と一緒に同梱されているcontribモジュールと、contribモジュール以外(サードパーティー)モジュールがあります。

contribモジュールは、PostgreSQL本体と合わせてリリースされていますので、PostgreSQLサーバのインストール時に一緒にインストールしておきましょう。contribモジュールをインストールしておけば、後からcontribモジュールに含まれる拡張を導入することが可能です。contribモジュール以外の拡張は、サードパーティーモジュールと呼ばれ、現在はGitHubサイトで公開されていることが多いです。ダウンロード可能な形式はソースコードがメインで、リリース時点で公開されているRHELのrpmファイルもダウンロード可能な場合もあります。

auto_explain(contrib)

設定した時間以上かかったSQLの実行計画をPostgreSQLログに出力します。今回のこの記事で一番紹介したかったのはこのauto_explain拡張モジュールです。

サポートでよく「SQLが突然遅くなった。」という問い合わせをいただきますが、遅くなった時の情報が何もないため、なぜ遅くなったのかの原因調査が出来ません。問い合わせをいただいた時の返答はいつも「次回遅延が発生している間にEXPLAIN (ANALYZE, BUFFERS) SQL;を実行して実行計画を取得してください。」とお伝えしています。遅延している状況がずっと続いている、または定期的に遅延していてその時間帯が日中の場合はEXPLAIN (ANALYZE, BUFFERS) SQL;を手動で実行して実行結果を取得することは可能ですが、遅延の発生が真夜中であるとか、遅延がいつ発生するのかが不明な場合は人手でEXPLAIN (ANALYZE, BUFFERS) SQL;を実行することは困難です。そのような状況で一番役立つのがこのauto_explainです。

auto_explainの使い方について説明します。postgresql.confに下記の設定を追加して、PostgreSQLを再起動するとauto_explainが有効になって、例えば10秒以上かかるSQLが実行されると自動的にSQL実行時のEXPLAIN(ANALYZE, BUFFERS) SQL;の情報がPostgreSQLログに出力されます。

PostgreSQLログにauto_explainでの実行結果が出力されれば、性能悪化時と通常時の実行計画を比較できます。
下記はauto_explainを使うために必要な設定で、設定追加後PostgreSQLを再起動すると10秒以上かかったSQL文の実行計画がPostgreSQLログに出力されます。

shared_preload_libraries = 'auto_explain'
auto_explain.log_min_duration = 10s
auto_explain.log_analyze = on
auto_explain.log_buffers = on
auto_explain.log_timing = off # ノードごとの実行時間を取得する場合はon

なお、auto_explainの有効化はデータベースサーバ全体だけではなく、セッション単位でも下記の方法で有効化可能です。下記の例は、psqlで接続した後、

db1=# LOAD 'auto_explain';
LOAD
db1=# set auto_explain.log_min_duration = 0;
SET
db1=# set auto_explain.log_analyze = on;
SET
db1=# SELECT COUNT(*) FROM pgbench_accounts;
count
--------
100000
(1 row)

db1=#

上記の実行でのPostgreSQLログ出力は下記となります。

2026-10-06 20:51:58.504 JST [5786] LOG: duration: 7.090 ms plan:
Query Text: SELECT COUNT(*) FROM pgbench_accounts;
Aggregate (cost=2924.00..2924.01 rows=1 width=8) (actual time=7.080..7.081 rows=1.00 loops=1)
-> Seq Scan on pgbench_accounts (cost=0.00..2674.00 rows=100000 width=0) (actual time=0.008..4.326 rows=100000.00 loops=1)

※注：auto_explain.log_analyzeを有効(on)にすると、すべてのSQL実行で性能上のマイナスが起こり得ます。auto_explain.log_timing = offを追加することでノードごとの時間情報が無効になりますが行数の情報は取得でき性能面での損失が改善されますので、本番環境では通常はauto_explain.log_timingを無効にしておくことが望ましいと考えられます。
実際に遅延が発生し、ノードごとの時間情報も必要と判断した場合のみ、性能面でのデメリットを認識した上でauto_explain.log_timing = onに変更し、情報が取得でき次第速やかに無効(off)にする運用がよいでしょう。

auto_explain(F.3. auto_explain — 低速な問い合わせ実行計画のログ)
https://www.sraoss.co.jp/PostgreSQL/Manual/document/18/auto-explain.html

pg_hint_plan(サードパーティー)

なお、今回紹介している性能調査とは異なりますが、auto_explainでPostgreSQLログに出力した実行計画が性能悪化の原因であった場合、SQLに埋め込んだヒント句で強制的に実行計画を変更するpg_hint_planという拡張も紹介しておきます。
オプティマイザ統計情報を最新化しても実行計画の形が変わってしまってSQLの性能が悪化した場合、例えば結合方式が速い時はHash Joinなのに遅延時はNested Loopに変更されてしまったとか、複数テーブルある結合で速い時と遅い時でテーブルを結合する順番が異なるなどの場合に、強制的に速い時の実行計画にあわせるためにSQLにヒント句を埋め込んでヒント句の通りに実行計画を強制変更します。SQLにヒント句を埋め込まない指定も利用可能です。弊社ブログに解説がありますのでご参照ください。

pg_hint_plan (PostgreSQL 実行計画制御ツール)
https://www.sraoss.co.jp/tech-blog/pgsql/pg_hint_plan/

pg_stat_statements(contrib)

pg_stat_statementsは日常的にどのSQLが時間を使っているのかを把握するための拡張です。短い実行時間のSQLでも実行回数が多ければ合計実行時間は大きくなります。pg_stat_statementsはサーバで実行されたすべてのSQLのプラン生成時と実行時の統計情報を記録します。このモジュールはPostgreSQLログへの出力は無く、情報の参照は情報を取得しているデータベースに接続してpg_stat_statementsビューをSELECTする方法となります。

下記はpg_stat_statementsを使うために必要な設定で、設定追加後PostgreSQLを再起動した後、利用するデータベースに接続してCREATE EXTENSION pg_stat_statements;を実行すると、pg_stat_statementsビューが参照可能となります。

shared_preload_libraries = 'pg_stat_statements'

DB再起動後、下記を実行。

db1=# CREATE EXTENSION pg_stat_statements;
CREATE EXTENSION
db1=# \dx
List of installed extensions
Name | Version | Default version | Schema | Description

--------------------+---------+-----------------+------------+----------------------------------------------------------------
--------
pg_stat_statements | 1.12 | 1.12 | public | track planning and execution statistics of all SQL statements e
xecuted
plpgsql | 1.0 | 1.0 | pg_catalog | PL/pgSQL procedural language
(2 rows)

db1=#

PostgreSQLマニュアルの実行例を実行した例。合計実行時間(total_exec_time)の多い順から、SQL、呼び出し回数、合計実行時間、行数、算出したヒット率が表示されています。

db1=# \x
Expanded display is on.
db1=# SELECT query, calls, total_exec_time, rows, 100.0 * shared_blks_hit /
nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5;
-[ RECORD 1 ]---+-----------------------------------------------------------------------------------------------------
query | UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2
calls | 3000
total_exec_time | 17180.62709200005
rows | 3000
hit_percent | 99.9982951155059245
-[ RECORD 2 ]---+-----------------------------------------------------------------------------------------------------
query | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
calls | 3000
total_exec_time | 14783.155679999958
rows | 3000
hit_percent | 99.9957805907172996
-[ RECORD 3 ]---+-----------------------------------------------------------------------------------------------------
query | UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2
calls | 3000
total_exec_time | 111.09148400000022
rows | 3000
hit_percent | 92.5940860215053763
-[ RECORD 4 ]---+-----------------------------------------------------------------------------------------------------
query | SELECT abalance FROM pgbench_accounts WHERE aid = $1
calls | 3000
total_exec_time | 28.88099300000003
rows | 3000
hit_percent | 100.0000000000000000
-[ RECORD 5 ]---+-----------------------------------------------------------------------------------------------------
query | INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES ($1, $2, $3, $4, CURRENT_TIMESTAMP)
calls | 3000
total_exec_time | 21.792536000000027
rows | 3000
hit_percent | 100.0000000000000000

db1=#

pg_stat_statements(F.32. pg_stat_statements — SQL文のプラン生成時と実行時の統計情報を記録する)
https://www.sraoss.co.jp/PostgreSQL/Manual/document/18/pgstatstatements.html

性能問題の調査に役立つ情報の継続収集

性能問題の調査では、問題発生時の状況だけでなく、過去との比較も重要です。
そのためには PostgreSQL の統計情報や OS のリソース情報を継続的に収集しておくことが有効です。

収集方法としては、

• sysstat(sar)
• 各種監視ツール
• PostgreSQL向け収集ツール

などがあります。
その中でも PostgreSQL の統計情報と OS リソース情報をまとめて時系列で取得できるツールとしてpg_statsinfo があります。

pg_statsinfo(サードパーティー)

pg_statsinfo は PostgreSQL の統計情報やOSリソース情報を時系列で取得・保存するツールです。PostgreSQL 統計情報やOSリソース情報を時系列で取得するスナップショットを保存するためのリポジトリDBが必要となりますが、pg_statsinfoを使った運用をしていると何か性能問題が発生した時に過去の情報を参照できるのでとても便利です。上で紹介したpg_stat_statementsと、ヒント句を取得できるpg_store_plansと併用することでクエリの統計情報と実行計画も一緒に保存できるため、どのSQLが性能に影響していた可能性があるのか、また実行計画の変化によって性能が悪化した時も後から確認できます。
弊社ブログに解説がありますのでご参照ください。

pg_statsinfo(統計・OSリソース情報時系列取得保存ツール)
https://www.sraoss.co.jp/tech-blog/pgsql/pg_statsinfo/

pg_statsinfoは現在も有用なツールですが、監視製品やクラウド環境の監視機能などを利用して継続収集を行う方法も合わせてご検討ください。

まとめ

PostgreSQLの性能問題は、「遅くなった」という事実だけでは原因を特定できません。重要なのは、問題発生時に何が起きていたのかを後から分析できる情報を残しておくことです。

本記事では、チェックポイント、自動VACUUM、自動ANALYZE、ロック待ち、遅延SQLを記録するためのログ設定と、遅延時の実行計画を自動取得できるauto_explain、調査結果を踏まえて実行計画を制御できるpg_hint_plan、SQL実行統計を蓄積するpg_stat_statements、PostgreSQLの統計情報やOSリソース情報を時系列で取得・保存するpg_statsinfoを紹介しました。

特に、SQL性能問題の原因究明においては、遅延発生時のEXPLAIN (ANALYZE, BUFFERS)の取得が最も重要です。auto_explainを導入しておけば、人が操作できない時間帯に発生した遅延であっても、実行計画を記録できます。遅延時の実行計画が通常時の実行計画と異なる場合は、pg_hint_planにより強制的に通常時の実行計画に合わせることが可能となります。ただし、実行計画変更の根本原因が統計情報やデータ分布の変化にある場合もあり、pg_hint_planは原因調査や恒久対策を行った上で必要に応じて利用します。

PostgreSQLの性能問題への対応は、問題発生後に慌てて調査方法を考えるのではなく、平常時から必要な情報を取得できる状態を作っておくことが重要です。本記事がそのための設定見直しの参考になれば幸いです。

2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。

本レポートでは、PGConf.EU 2026 Day3で発表された講演のうち、筆者が印象に残ったセッションを紹介します。

Where next for parallel query execution?

Thomas Munro 氏は、PostgreSQL の並列クエリ実行における課題と今後の改善の方向性について解説しました。

重要な課題の1つとして挙げられたのが、メモリ管理です。現在の PostgreSQL では、ソートやハッシュ結合などの処理ごとに、主に work_mem パラメータを上限値としてメモリ使用量を制御しています。
しかしながら、各処理がメモリを確保・解放するタイミングは実行計画や実行時の状況によって異なるため、単純な掛け算ではピーク時の使用量を正確に把握できず、システム全体で実際にメモリがどの程度使用されるのかを予測することは困難です。

work_mem を大きなサイズに設定すると OOM によるプロセス終了などの危険がある一方で、安全性を重視してwork_mem を小さくすると、利用可能なメモリを十分に活用できません。
特にクエリを複数プロセスで並列に実行する場合には、より多くのメモリを消費する可能性があるため、メモリ管理の重要性も高くなります。

この課題に対して、各処理ごとのメモリ管理ではなく、クエリ単位、さらにはシステム全体でメモリを管理する方向性が示されました。まず、クエリ実行時のピークメモリ使用量を計測し、EXPLAIN (ANALYZE) で表示できるようにしたり、共有メモリを通じて参照可能にすることが提案されました。さらに、プランニング時にはピークメモリ使用量を推定して EXPLAIN で表示できるようにする案も紹介されました。

また、クエリの実行開始を制御する Admission Control のアイデアも紹介されました。システム全体で利用可能なメモリ量を管理し、クエリごとに推定される使用量を事前に予約しておく仕組みです。メモリが不足する場合には、実行を待機させるか、work_mem を小さくして実行する方法が考えられています。

これらの改善は今後の検討課題ですが、もし実現すれば、並列クエリ実行において、安全性とリソース利用効率を両立した、より適切なメモリ管理につながる可能性があります。今後の動向に注目です。

The process of RPM packaging in the PostgreSQL ecosystem

Devrim Gündüz 氏は、PostgreSQL エコシステムにおける RPM パッケージの作成・保守プロセスと、その運用上の課題について解説しました。

PostgreSQL の RPM リポジトリでは、膨大な数のパッケージを管理しており、PostgreSQL 本体だけでなく、拡張機能やバックアップツールなども提供しています。

RPM パッケージの作成には、ビルド手順や依存関係、インストールするファイルなどを定義した Spec ファイルを使用します。パッケージングでは、Spec ファイルの作成に加え、依存関係の確認、セキュリティ検査、各 OS や PostgreSQL のバージョンとの互換性確認など、多くの作業が必要です。また、PostgreSQL が依存するライブラリなどのパッケージ名は Linux ディストリビューションによって異なるため、Spec ファイルには複雑な条件分岐が必要になるなど、多彩なディストリビューションにパッケージを提供しているPostgreSQLならではの苦労も語られました。

こうした作業を効率化するため、Claude などの AI を活用し、自動化ツールやテストコードの作成など、日常的なメンテナンス作業の効率化にも取り組んでいることが紹介されました。

特に印象的だったのは、RHEL の OpenSSL 更新に伴う互換性問題です。(参考: https://www.postgresql.org/about/news/postgresql-rpm-repository-now-supports-multiple-rhel-minor-versions-3202/)
2025年にリリースされた RHEL 9.7 および 10.1 では、OpenSSL のバージョン更新によって、以前のマイナーバージョン向けの RPM との間で依存関係の問題が発生しました。これを受けて、PostgreSQL の RPM リポジトリでは、RHEL 9 と 10 のそれぞれについて最新 2 つのマイナーバージョンをサポートし、マイナーバージョンごとに RPM をビルドする方針に変更しました。この対応に伴う作業負担は大きく、「ストレスの多い1月を過ごした」と語られたことが印象に残っています。

講演を通じて、RPM パッケージの提供は単なるビルド作業ではなく、OS の変更への対応や、セキュリティと品質の継続的な確保など、多くの保守作業によって支えられていることが実感できました。

Can We Skip Recovery? The Architecture of On-Demand WAL Replay

Srinath Reddy Sadipiralla 氏は、PostgreSQL のクラッシュリカバリを高速化する「On-Demand WAL Replay」の実験的なアーキテクチャについて解説しました。

現在の PostgreSQL では、クラッシュ後の起動時にリカバリが実行され、チェックポイント以降の WAL をすべて再生する必要があります。これが完了するまでクライアントは接続できないため、WAL の量が多いほどサービス停止時間が長くなる問題があります。

これを解決するために提案されている「On-Demand WAL Replay」では、起動時のリカバリで WAL すべてをスキャンする一方、テーブルやインデックスなどのデータページを変更する WAL レコードの適用を遅延させます。未適用の WAL レコードはページごとに共有メモリ上で管理し、ページへの初回アクセス時や、バックグラウンド処理によって適用されます。これにより、すべてのページの復旧を待たずにクライアントからの接続を受け付けられるようになります。

性能評価では、接続可能になるまでの時間が最大 5.5 倍高速化しました。一方で、初回アクセス時の遅延や、未復旧ページが存在する間のチェックポイントの制限、共有メモリの消費などが課題として挙げられました。今後はリプレイ処理の並列化や、管理情報のディスクへの退避などが検討されています。

講演の終わりには、本機能のバグ報告など、開発への協力が呼びかけられました。このように、開発中の機能についてフィードバックを募れることも、カンファレンスを開催する重要な意義であると感じました。

まとめ

以上、PGConf.EU 3日目の講演レポートでした。
本日最後に行われたクロージングセッションによると、今回の参加者は 747 名、講演数は 101 講演だったとのことです。改めて、規模の大きいイベントであると感じました。

3日間を通して、PostgreSQL の内部構造や新機能、運用上の課題など、幅広いテーマの講演を聴くことができました。また、講演後の活発な質疑応答や参加者同士の交流からも、PostgreSQL コミュニティの活気を感じました。技術的な知見だけでなく、今後の PostgreSQL の発展に向けた取り組みを知ることができた、有意義な 3日間でした。

2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。

本レポートでは、PGConf.EU 2026 Day2で発表された講演のうち、筆者が印象に残ったセッションを紹介します。

Autovacuum Is Running. Is It Actually Working?

Teresa Lopes 氏は、PostgreSQL の autovacuum が適切に動作しているかを確認する方法と、効果的なチューニングについて解説しました。

PostgreSQL の MVCC の仕組みでは更新前の行がテーブルに残るため、不要になった行（dead tuple）を VACUUM で回収する必要があります。autovacuum はこの処理を自動化しますが、デフォルト設定が必ずしも最適とは限りません。
講演では、autovacuum の起動条件を決めるしきい値とスケールファクターの影響を実験で比較しました。小規模テーブルではautovacuum_vacuum_threshold、大規模テーブルではautovacuum_vacuum_scale_factorの調整が重要です。また、コスト上限やコスト遅延、ワーカー数を調整することで、システム負荷と処理時間のバランスを改善できることを示しました。

一方、長時間トランザクションや放置されたレプリケーションスロットなどが VACUUM の処理を妨げる場合があります。さらに、通常の VACUUM ではテーブルやインデックスの肥大化を完全には解消できず、REPACK や REINDEX などが必要になることも説明しました。

最後に、PostgreSQL 19 に向けた改善にも触れ、autovacuumが適切に動作しているかを監視可能になる機能改善が多数あることが紹介されました。
PostgreSQLを運用する上でautovacuumは重要な役割を果たしていますが、適切に動作させることは難しい印象です。弊社のサポートでもautovacuumについての問い合わせは数多くあります。講演者がautovacuumのチューニングに対する苦労を語っていた点に共感しました。

How to Contribute to the PostgreSQL Documentation

David E. Wheeler 氏は、PostgreSQL の公式ドキュメントを改善し、コミュニティに貢献する方法を紹介しました。

PostgreSQL のドキュメントは XMLベースのマークアップ言語である DocBook で管理されており、Emacs や Vim などのテキストエディタで編集できます。章や段落、リンク、表、コマンドの実行例などは専用のタグで記述されます。修正後は make check で構文を検証し、HTML や PDF を生成して内容を確認できます。
変更を提出する際は、git diff で差分を確認し、git format-patch でパッチを作成します。PostgreSQL では GitHub の Pull Request ではなく、メーリングリストにパッチを投稿する方法が基本です。投稿後は CommitFest に登録することで、レビュー状況を追跡できます。
講演者は、機能の開発者でなくても、利用者として疑問に感じた点や分かりにくい説明を改善することで、PostgreSQL の発展に貢献できると強調しました。

講演内では、ドキュメントを改善してコミュニティにパッチを投稿するまでの一連の流れが紹介されており、この講演を聞けば今にでもパッチ投稿できそうなところが良かったです。また、PostgreSQLのドキュメント内で使用されている DocBook のタグについても丁寧な解説があり、非常に参考になりました。

Security Strategies for your database backups

Priyanka Chatterjee 氏は、PostgreSQL のバックアップを安全に保護するための戦略について解説しました。

データベース本体ではロールや権限、パスワード、SSL/TLS などのセキュリティ対策が重視されますが、バックアップについては取得や復元の成否、処理時間に注目が集まり、セキュリティ対策が後回しになりがちです。

バックアップの保管先が適切に保護されていないと、攻撃者に機密データを読み取られたり、バックアップファイルを改ざんされたりする可能性があります。改ざんされたバックアップを使用すると、不正なデータや設定が復元先に持ち込まれ、復旧後のシステムに新たな問題が発生する恐れもあります。また、ランサムウェア攻撃では、データベース本体だけでなくバックアップも標的となり、復旧手段を奪われる可能性があります。そのため、バックアップをデータベース本体と同じ権限やネットワークの中だけで管理することには注意が必要です。

バックアップの保管方法として、元データを含めて 3 つのコピーを保持し、2 種類の異なる媒体に保存し、少なくとも 1 つのコピーをオフサイトに保管する「3-2-1 戦略」が紹介されました。さらに、定期的な復元テストを実施し、バックアップから正常にデータベースを復旧できることを確認することも重要です。

セキュリティ対策としては、バックアップの暗号化とアクセス制御が挙げられました。クラウドストレージでは、KMS（Key Management Service）を利用した暗号鍵の管理に加え、ストレージへのアクセス制御やパブリックアクセスの制限が有効です。また、VPC やプライベートエンドポイントなどを活用したネットワーク経由のアクセス制限や、転送時の暗号化によって、バックアップへの不正アクセスや情報漏えいのリスクを低減できます。

近年、個人情報の流出事故が相次いでおり、データベースのセキュリティ対策はますます重要になっています。今回の講演を通じて、データベース本体だけでなく、バックアップの保管方法や暗号化、アクセス制御まで含めて適切に設計することの重要性を改めて感じました。

まとめ

以上、PGConf.EU 2 日目の講演レポートでした。
PostgreSQL本体の開発に参加するための方法や、開発を行ってみての知見を発表するセッションが複数あることが、本イベントの特色のうちの1つであると感じます。PostgreSQL開発コミュニティへ貢献することへの関心の高さを感じました。

2026年は10月20日から23日にかけてスペイン・バレンシアで開催されます。

本レポートでは、PGConf.EU 2026 Day1で発表された講演のうち、筆者が印象に残ったセッションを紹介します。

オープニングセッション

オープニングセッションでは、イベントの説明がされたのち、PostgreSQLとPostgres Europeの30年にわたる歴史を振り返りました。1996年頃のPostgreSQL 6.0から始まり、2008年のPostgres Europe設立、2014年のマドリード開催、コロナ禍を経たカンファレンスの復活などの紹介がありました。一番重大なトピックとして、PostgreSQL EUのマスコットとしてSlonikというマスコットキャラクターがいるのですが、今年その着ぐるみが代替わりしたそうです。新しいSlonikマスコットのお披露目や旧着ぐるみの抽選企画も発表され、会場は笑いに包まれました。

 REPACK in Core

Robert Treat 氏による、PostgreSQL 19 に導入予定の REPACK コマンドについての解説です。
PostgreSQL では、MVCC によってテーブルやインデックスが肥大化することがあります。いったん肥大化したテーブルは通常のVACUUMでは縮小できず、強いロックが必要なVACUUM FULLを実行する必要があります。

PostgreSQL 19では、VACUUM FULLの名前がREPACKに変更されました。このことにより、通常のVACUUMとの区別がしやすくなるという利点があります。
また、REPACK CONCURRENTLY機能が追加され、通常のデータベース操作への影響を抑えながら再編成できます。

REPACK CONCURRENTLY は、論理デコードを利用して更新を追跡しながら、新しいテーブルへデータをコピーします。最後に短時間の排他ロックを取得してファイルを切り替える仕組みです。

ただし、長時間トランザクションとの競合や MVCC 安全性、REPACK実行中の更新行数の上限、メモリ消費など、運用上の制約が残っています。また、実行できないテーブルもあり、複数のREPACK CONCURRENTLYを同時に実行することも推奨されていません。

講演者は、現時点では既存の pg_repack を完全に置き換えるものではないと説明しました。特に、多数のテーブルを定期的に再編成する用途では、引き続き pg_repack が有用です。

制約が多数あり、PostgreSQL 19時点では本番環境で実行することは難しい機能だと感じました。しかし、テーブルへの更新や参照をブロックしないテーブル再編成機能はニーズの高い機能であり、PostgreSQL 本体にREPACK CONCURRENTLY機能が導入されることは大きな進歩です。今後の改善が期待されます。

pg_ivm の最近の改善と方向性

弊社の長田からは、PostgreSQL のマテリアライズドビューを高速に更新するための拡張モジュール pg_ivm の最近の改善と今後の方向性について紹介されました。

pg_ivm は、Incremental View Maintenance（増分ビューメンテナンス）を PostgreSQL 上で実現する拡張機能です。通常のマテリアライズドビューでは、基となるテーブルの更新内容を反映するために REFRESH MATERIALIZED VIEW を実行してビュー全体を再計算する必要がありますが、pg_ivm は変更差分のみを計算して適用することで、自動的かつ効率的に更新されるマテリアライズドビュー（IMMV, Incrementally Maintainable Materialized View）を作成することができます。

講演では、増分メンテナンスによってビュー更新を高速化できる一方、元テーブルの更新時には差分計算やビュー更新が発生するため、一定のオーバーヘッドや同時実行性への影響があることも説明されました。

最近の機能改善としては、Outer Join（外部結合）のサポート、pg_dump および pg_upgrade への対応強化、PostgreSQL 19 への対応などが紹介されました。特に Outer Join のサポートが大きな技術的成果として取り上げられました。Outer Join では、結合相手が存在しない場合に生成される NULL で補完された行（dangling tuple）が存在するため、単純な増分メンテナンスでは適切に対応できません。pg_ivm では、Outer Join の結果を 通常の内部結合で得られる部分と、結合相手を持たない行に影響する部分に分けて扱うことで対応しています。また、以前は pg_dump によるダンプデータのリストア時やpg_upgrade によるアップグレード後にpg_ivmのメタデータが正しく復元されない問題がありました。これらについても、メタデータを復元する関数を実装することなどにより、適切にデータ移行できるように改善されました。

今後の開発では、Deferred Maintenance（遅延メンテナンス）が大きな候補として挙げられました。テーブル差分の収集とビューの更新を分離し、後からまとめてメンテナンスできるようにすることで、テーブル更新性能への影響を軽減しながら、増分メンテナンスの利点を活用できるようになることが期待されます。

Community Moments That Shaped 30 Years of PostgreSQL

Valeria Kaplan 氏による、イベントを通じて発展してきた PostgreSQL コミュニティの歴史を振り返るセッションです。 PostgreSQL は、1990 年代の開発者同士の交流から成長し、現在では世界各地でカンファレンスやミートアップが開かれています。

PostgreSQLの開発はメーリングリスト上で行われていると思われていますが、実はこのようなコミュニティイベントによる交流の力も大きいです。メーリングリストだけでは生まれにくい信頼関係や協力関係を育むことで、新機能の開発につながっています。

コミュニティイベントの開催は主に企業、登壇者、運営者によって支えられています。企業はイベント協賛の形で資金提供を行いますが、イベントへの協賛は、人材採用や認知度向上、開発動向の把握に役立ちます。一方、登壇者は講演を準備する労力を支払う一方で、知識の共有や成長の機会を得られます。運営者は多くの時間と労力を費やしますが、コミュニティに貢献する誇りや仲間とのつながりが活動を支えています。

今後の課題として、新しい登壇者や運営ボランティアの参加を増やしていくこと、多様性を向上させること、学生や他の技術コミュニティとの交流を拡大することが挙げられました。講演者氏は、小さな貢献でも大きな変化につながる可能性があるとして、積極的な参加を呼びかけています。PostgreSQLの発展にはコミュニティへの貢献が不可欠ですので、筆者も何らかの形で貢献したいと考えています。

まとめ

以上、PGConf.EU 1 日目の講演レポートでした。
初日に参加した感想としては、多くの参加者が集まり、質疑応答も活発に行われるなど、非常に活気のあるイベントだと感じました。休憩時間や昼食時には、軽食を片手に参加者同士が交流する姿も見られました。講演内容も、PostgreSQL の内部構造に踏み込んだ技術的な話から、ユーザー視点での実践的な Tips の紹介まで多岐にわたり、様々な観点からPostgreSQLについての情報収集ができるイベントだと感じます。

2026年秋、PostgreSQL 19が、いよいよ登場します。

PostgreSQLの最新情報を効率よく把握したい方に向けて、
SRA OSS主催の「PostgreSQL 19 リリース記念ウェビナー」を開催します！

 セミナーの内容を見てみる

開催概要

タイトル	PostgreSQL 19 リリース記念セミナー ～ いよいよ登場！～ 新機能の要点をコントリビューターが解説 ～
日時	2026 年 10 月 27 日（火）14:00 ～ 15:30
視聴方法	Zoom Webinar によるライブ配信
費用	無料（事前登録制）
主催	株式会社SRA OSS

★ このウェビナーで得られること

• PostgreSQL 19の主要な新機能や要点を短時間で把握できる
• アップグレード時に確認すべきポイントが分かる
• PostgreSQL 19の実運用への影響や活用方法のヒントを得られる
• その場で質問でき、回答が得られる

本セミナーでは、PostgreSQL 19のリリースを記念し、PostgreSQL Significant Contributor（※）として活動する講師が、PostgreSQL 19の主要な新機能の要点を約1時間でわかりやすく解説します。
（※）PostgreSQL Significant Contributor：PostgreSQLの開発や普及活動への継続的な貢献が認められた技術者

また、セミナー中いつでも講演内容に関する質問ができるリアルタイムQ&Aセッションも予定しております。リリースノートや技術資料を読むだけでは理解しきれないポイントを、その場で講師に質問できるライブ配信ならではの機会です。

PostgreSQL 19 技術検証レポート公開中
PostgreSQL 19の技術検証結果をまとめたレポートを公開しています。
セミナーの予習・復習資料としてぜひご活用ください。
https://www.sraoss.co.jp/tech-blog/pgsql/pg19report/

プログラム

PostgreSQL 19 新バージョン解説

近年のメジャーリリースの中でも機能追加や改善項目が多いPostgreSQL 19 について、beta版での検証結果を交えながら新機能のポイントをわかりやすく解説します。

PostgreSQL 19 の主なトピック
・タプルデフォーム高速化やSIMD利用拡大などの性能向上
・COPYコマンド拡張やJSON機能強化などのSQL機能
・AutovacuumスコアやREPACKコマンドなどの運用管理機能
・シーケンスの論理レプリケーション対応
・プランナヒント機能
・非互換の変更点
・今回のリリースで見送られた機能

講師：株式会社SRA OSS　データベース技術グループ　コンサルタント
高塚　遥（PostgreSQL Significant Contributor）

リアルタイムQ&Aセッション

毎年ご好評いただいているQ&Aセッションです。
ZoomのQ&A機能に寄せられた質問に対し、講師がリアルタイムで回答・解説します。
※質問数や進行状況により、すべてのご質問にお答えできない場合があります。

PostgreSQL 19で何が変わるのか。
そして、その進化をどのように活かせるのか。
新バージョンの全体像を短時間で把握できる機会です。ぜひご参加ください！

はじめに

Zabbix Summit 2026 レポートの2日目では、大規模な監視環境を支える技術的な工夫から、収集したデータの活用、ビジネスサービスの信頼性管理まで、幅広いテーマの講演をいくつかピックアップして紹介します。

今回取り上げる講演では、毎秒 100 万件の新規監視値を扱うための性能面の工夫や、日々の運用を効率化する機能、製造現場の業務アプリケーションを支える監視事例が紹介されました。さらに、Zabbix が収集したデータをレポートや AI による異常検知に活用する方法や、サービス全体の状態を可視化して SLA の管理につなげる取り組みも取り上げられました。

これらの講演に共通しているのは、監視データを収集して異常を通知するだけでなく、その情報を運用の改善や業務上の判断に役立てようとしている点です。それぞれの講演から、Zabbix の機能をどのように活用し、監視の効率化やサービスの安定運用につなげているのかを見ていきます。

大規模監視と日々の運用を支える Zabbix の工夫

Aleksandrs Kalimulins 氏の講演「Achieving 1M NVPS and Other Little Things」では、毎秒 100 万件の新規監視値を扱うというテーマとともに、日常の運用に役立つ Zabbix の機能が紹介されました。エージェント設定の簡素化からプロキシの運用、マクロによる通知の改善、ブラウザー監視まで、規模の拡大と使いやすさを両立するための工夫が幅広く取り上げられました。

■ エージェントの設定を整理する

エージェントの設定では、ホスト名の取得方法や、長いアイテムキーとパラメータの扱いが話題になりました。環境ごとに異なる情報をどこで設定するかを整理することで、テンプレートの再利用と保守をしやすくできます。短い別名やユーザーパラメータの活用は、複雑な設定を扱いやすくするための手段として紹介されました。

また、単一のエージェントを複数の論理的なホストとして利用する考え方も示されました。アクティブ監視では複数のホスト名を設定する方法があり、パッシブ監視では複数のホストから同じエージェントの接続先を参照できます。同じマシン上の監視対象を分けて管理したい場合に役立ちます。ただし、監視対象をどう分けるかは、テンプレートやパラメータの管理方針と合わせて考える必要があります。

導入を支援する機能として、ホストウィザードも紹介されました。画面の案内に従って設定を進め、生成されたコマンドを実行することで、エージェントの導入を進められます。設定に不慣れな担当者でも、必要な作業を段階的に確認できることが利点です。

■ 分散監視を支えるプロキシ

プロキシについては、収集データの保存方法として、ディスク、メモリ、ハイブリッドという選択肢が説明されました。メモリを使う方式は、収集データのバッファリングに伴うデータベースへの書き込みを抑えられます。ハイブリッド方式はメモリとデータベースを組み合わせるもので、通信状況やデータ保持の要件に応じた使い分けが重要です。軽量な SQLite は、遠隔拠点での運用やデータベースの再作成の容易さという観点から取り上げられました。設定の同期頻度についても、回線帯域や接続の安定性を考慮して調整できます。必要なタイミングで手動の設定更新を行う方法も紹介され、拠点ごとの事情に合わせた運用が示されました。

さらに、対応する範囲で異なるバージョンのプロキシを利用し、サーバーとプロキシを段階的に更新する考え方が説明されました。大規模環境では、すべての拠点を一斉に更新する負担を減らせます。プロキシ側でシークレットマクロを解決する機能も取り上げられ、拠点や役割に応じた秘密情報の取り扱いが話題になりました。

■ トリガーと通知を理解しやすくする

複雑なトリガー式は、設定を読むだけでは判定の理由を把握しにくい場合があります。講演では、マクロや式の構成要素を実際の値に展開して確認し、条件を読み解くための機能が紹介されました。複数のテンプレートや条件を組み合わせた監視では、こうした確認機能が調査を助けます。

通知の内容を充実させる方法として、値や時刻を示すマクロ、式マクロ、文字列変換などのマクロ関数も説明されました。例えば、ディスク容量の問題を知らせる際、対象のファイルシステムや残り容量をメッセージに含めれば、通知を受けた時点で状況を把握しやすくなります。異常の発生だけでなく、対応に必要な情報まで伝えることがポイントです。

■ ウェブ監視と表示機能の活用

ウェブシナリオでは、応答から JSONPath や XPath で値を抽出し、後続のステップで利用する方法が紹介されました。複数のリクエストをつなぐ REST API のテストなどに活用できます。ブラウザーアイテムについては、ログイン操作だけに用途を限定せず、自動操作の仕組みをさまざまな確認に応用する考え方が示されました。Appium を利用したモバイルアプリケーションのテストや、スクリーンショットの取得も話題になりました。一方、ブラウザーポーラーは同期的に処理するため、各チェックの所要時間、実行数、タイムアウトを考慮する必要があります。操作を自動化するだけでなく、監視を継続できる処理能力を見積もることが大切です。

このほか、ダッシュボードの操作性、アイテム履歴ウィジェット、ホストやテンプレートを探すグローバル検索も紹介されました。HTTP エージェントを使った Prometheus エクスポーターからのデータ取得にも触れられ、既存の監視資産を取り込む方法が示されました。

■ 毎秒 100 万件をテーマとした性能検証

講演の終盤では、ClickHouse と連携した構成での性能検証が紹介されました。履歴同期処理やバッファー、保存先の設定を調整し、書き込み先に過剰な負荷をかけないようにする工夫が説明されました。強調されたのは、瞬間的なピークではなく、単一の Zabbix サーバーノードで継続して処理できる負荷として評価する姿勢です。実測値は安定して 毎秒 100 万件処理を続けられることが説明されました。今回の講演は、大規模な処理性能と、日常の小さな運用改善を結び付ける内容でした。データ収集、保存、通知、画面操作をそれぞれ見直すことで、扱いやすく拡張しやすい監視環境につながると実感しました。

Zabbix の監視データを活用する ― AI による異常検知と高度なレポート機能

Wolfgang Alper 氏の講演「Putting Zabbix Data to Work: AI-Based Anomaly Detection and Advanced Reporting」では、Zabbix が収集している大量の監視データを、単なる監視結果として見るだけでなく、Reporting、外部連携、AI-Based Anomaly Detection に活用する方法が紹介されました。Alper 氏は、Zabbix はデータ収集に非常に強い一方で、収集した情報をそのまま監視画面の中だけで使うのではなく、Business Insight に変換することが重要だと説明しました。

■ レポート作成と外部システム連携によるデータ活用

まず紹介されたのが、Widget ベースの Reporting Engine です。考え方は Zabbix ダッシュボードに近く、レポートを複数の Widget の組み合わせとして構成します。Availability、Problem History、Current Problem、Long Running Problem、Graph、Markdown など、用途ごとに異なる Widget を利用でき、Management 向けレポートに必要な背景説明や補足情報も追加できます。レポートの元データは Zabbix API から取得し、Trend だけでなく Alert、Problem、Audit Log など幅広い情報を利用します。

収集したデータは Render Process を通して、人が読むレポートに変換することも、外部システムが再利用できるデータに変換することもできます。人向けには PDF レポートを生成でき、Header、Logo、Title、Table of Contents、Page Number などを含む形式で出力されます。各 Widget は Card のように レポート内へ配置され、Service Availability、MTTR、Problem State、Host Graph などを視覚的に確認できます。一方、システム連携向けには JSON、XML、CSV 形式でのエクスポートに対応し、BI Tool、Spreadsheet、Database、External Dashboard、Message Bus などにデータを渡せます。

講演では、既存データから新しい KPI を作る例として、Mean Time to Interaction や Mean Time to Recovery が紹介されました。Zabbix Event API に既に存在する情報を使って、Tech Support Team が Incident に対応するまでの平均時間や、Incident が Close されるまでの時間を算出できます。つまり、新しいデータを収集しなくても、既存の監視データから Management に有用な指標を作れるという点が重要です。

また、外部システムごとに必要なデータフォーマットが異なる場合に備えて、Transformation レイヤも用意されています。JavaScript の transform Function を使い、Report Object に対してフィールドの追加、削除、値の変更、新しい KPI の生成、Flatten 処理、Schema の変更などを実行できます。例えば外部システムが Report ID を必要とする場合は新しい フィールドを追加し、SLI と SLA の条件を比較して Boolean 値を生成することもできます。さらに、レポートデータを OpenTelemetry Collector が扱える形式に変換する例も紹介されました。

こうした仕組みにより、Zabbix で収集したデータを他部門や別アプリケーションに連携し、監視システムを企業全体のデータソースとして活用できます。特に大規模組織では、監視データを Kafka などの Message Bus に流し、別 Department や Business Application が Subscriber として利用する構成も考えられます。

■ 外部 AI Model による異常検知

講演後半では AI-Based Anomaly Detection も紹介されました。考え方は、Zabbix から取得した Time Series Data を外部 AI Model に入力し、各 Value が通常の Behavior からどの程度外れているかを Score として返すものです。複数の Model を同時に利用する Ensemble 構成も可能で、例えば 5 個の Model のうち 3 個以上が Anomaly と判断した場合に、最終的に異常として扱うような Majority Vote も設定できます。利用する Model 数を増やせば判定の信頼性を高められますが、その分 AI Server の Resource も必要になります。

AI 側からは Anomaly Score や Segment Score、さらに Trigger 作成の参考になる Threshold などが Zabbix に返されます。これらの値は通常の Zabbix Item と同様に ダッシュボードで確認でき、Trigger Expression に利用できます。つまり、Zabbix 本体の Source Code を変更せず、既存の アイテム、トリガー、ダッシュボードの仕組みを活用しながら、外部 AI Model による Anomaly Detection を組み込める点が特徴です。

■ 収集したデータを新たな価値につなげる

講演の Takeaway として強調されたのは、「もっとデータを集めること」よりも「すでに集めているデータをもっと賢く使うこと」です。監視システムには Infrastructure、Application、Business Activity など大量の情報が蓄積されています。それらは単なる監視用データではなく、企業にとって価値のある Asset です。

Zabbix が収集したデータをレポートに変換し、Management が理解しやすい KPI として提示し、JSON、XML、CSV などで外部システムに渡し、必要に応じて AI Model で Anomaly Detection を行うことで、Monitoring の役割を大きく拡張できます。今回の講演は、Zabbix を「異常を通知する Tool」だけでなく、「企業データを集約し、加工し、外部へ活用するプラットフォーム」として捉える実践的な事例でした。

Zabbix のサービス監視を活用した BSM と SLA 管理

Marek Panečný 氏の講演「Improving Service Reliability With Zabbix SLA Monitoring」では、Zabbix の Service Monitoring 機能を Business Service Monitoring、いわゆる BSM の考え方で活用し、単なる障害監視からサービス全体の信頼性管理へ発展させる方法が紹介されました。Panečný 氏は Asseco CEIT で監視基盤を担当しており、長年さまざまな監視製品を扱ってきた中で、2013 年頃から Zabbix を主要な監視ソリューションとして利用していると説明しました。

■ サービス全体の状態を可視化する BSM と SLA 監視

一般的な IT 環境は、Hardware、Operating System、Network、Database など複数のレイヤで構成されています。従来の監視では、それぞれのレイヤに対して Item や Trigger を大量に設定し、「何も気付かないまま壊れる」ことを避けるようにします。この方法自体は正しいものの、監視対象が増えるほど Problem や Notification も増え、いわゆる Alert Flood が発生しやすくなります。また、個々の Component の状態は分かっても、「その障害が Business Service にどの程度影響しているか」までは分かりにくいという課題があります。

そこで BSM では、通常の監視レイヤの上に Business レイヤを追加します。その中心となるのが Service Tree です。Service Tree は、Service や Service Component を Node として表し、それらの関係性を Tree 構造として定義するものです。各 Node には Severity や Status があり、下位 Node の状態を上位 Node に伝播させることで、サービス全体への影響を可視化できます。また、この Service Tree があることで、SLA Report、Impact Analysis、Root Cause Analysis といった処理の基盤を作ることができます。

Zabbix は標準機能として、Service Tree の構築、Problem と Service Node の関連付け、伝播や相関のルール、さらに各 Service に対する SLA 設定を提供しています。Problem と Service Node の紐付けには Tag を利用できるため、特定の Problem Severity や条件を Service の状態へ反映できます。そのため、Business Service Monitoring の基本機能は標準の Zabbix だけでも構築可能です。

■ 独自の Widget と Module によるサービス監視の強化

一方で、講演では標準機能の弱点も指摘されました。最も大きな課題は Service Tree の表示方法です。Zabbix 標準では Service Tree を本当の Tree 形式ではなく Table 形式で表示するため、構造が複雑になるほど関係性を直感的に把握しづらくなります。また、Service Tree をダッシュボード上に表示する専用 Widget がなく、Service Tree 自体の自動生成機能もありません。そのため、大規模環境では構築や保守を手作業で行う必要があります。

この課題を補うため、Asseco CEIT では 2 つの Widget と 1 つの Module を独自に開発しました。

• Service Tree Widget
  これは Service Tree を実際の Tree 構造としてダッシュボード上に表示します。Node に Mouse Pointer を合わせると詳細情報を表示でき、対象 Service の Status や Severity が時間とともにどのように変化したかも確認できます。
• Service History Report Widget
  これは複数の Service Node の状態変化を時間軸で表示し、Downtime の割合や継続時間、最終状態変更時刻などを確認できます。Service の信頼性を履歴として把握できるため、SLA の評価や障害傾向の確認にも役立ちます。
• Impact Analysis Module
  これは Problem 一覧から特定の Problem を選択した際に、その Problem が Service Tree のどの Node に影響しているかを表示します。Problem から直接 Impact Analysis を開始できるため、単に「障害が発生した」という情報だけでなく、「どの Business Service に、どの範囲で影響しているか」を素早く把握できます。

これらの拡張機能を標準の Zabbix Service Monitoring と組み合わせることで、CIO、Service Owner、Manager など、技術詳細より Business Impact を重視する利用者にも分かりやすい Monitoring が可能になります。Service Tree を視覚的に確認し、Node ごとの履歴や SLA を把握し、Problem から Impact Analysis を行い、さらに Service Node の状態変化を Alert の起点として利用することもできます。

■ SLA 監視をサービスの信頼性向上につなげる

今回の講演のポイントは、Zabbix の Service Monitoring 機能は単なる補助機能ではなく、Business Service Monitoring を実現するための重要な基盤になり得るという点です。一方で、Service Tree の Visualization や自動生成にはまだ改善の余地があり、今後は Automatic Discovery や Service Tree の自動構築機能が加わることで、さらに実用性が高まることが期待されています。

ラリーカー製造を支える Teamcenter 監視―― PLM を止めないための実践

Marko Väätänen 氏の講演「Keeping PLM at Full Throttle: Teamcenter Monitoring in Rally Cars Manufacturing」では、ラリーカー製造で利用する Teamcenter を対象に、Zabbix による監視の実践が紹介されました。中心となるテーマは、サーバーの稼働状況だけでなく、アプリケーションや業務の流れまで把握し、製造を支える PLM（製品ライフサイクル管理）環境の安定運用につなげることです。講演では、本番環境のダッシュボードや通知の例を交えながら、現場で必要とされる監視の考え方が説明されました。

■ 正常な状態を定義し、監視の範囲を広げる

監視を設計する出発点は、何をもって正常と判断するのかを定義することです。Teamcenter が正常に機能しているかを判断するには、その基盤となるサーバーやデータベースに加え、関連するサービスや自動化処理にも目を向ける必要があります。講演では、一般的な基盤監視と Teamcenter 固有の監視項目を組み合わせ、必要な情報を収集する構成が紹介されました。

具体的な対象として挙げられたのは、データベースの状態、アプリケーションのプロセスごとのメモリ消費量、ファイルの欠落、Windows イベントログなどです。メモリリークの検出も監視対象に含まれており、サービスが起動しているかどうかだけでは分からない問題を捉えようとしています。メモリ使用量をグラフで確認することで、ある時点の値だけでなく、時間の経過に伴う変化を追える点も紹介されました。

■ 業務のワークフローに踏み込む

この事例で注目したいのは、Teamcenter 固有のワークフローを監視対象としている点です。基盤側の状態を確認するだけでなく、アプリケーション内部の処理が期待どおりに進んでいるかを追跡する視点が示されました。処理の連鎖の中に問題があっても、監視がなければ担当者が気付けない場合があるという説明は、業務に近い層を可視化する重要性を表しています。

一方で、ワークフローから必要な情報を取り出す作業は、簡単ではないことも語られました。どの情報を取得したいのか、どの条件で結果を抽出するのかを明確にし、Teamcenter のデータベースや処理の構造に合わせて設定する必要があります。
講演では、UserParameter を使った情報取得や、特定のイベントに対応するトリガーの設定にも触れられました。監視項目を増やすだけでなく、業務上の問題を判断できる情報に整えることが、実装上の要点として読み取れます。

■ ダッシュボードで利用状況をまとめて確認する

本番環境の監視画面では、サービスの状態とともに、ユーザー数やログインに関する情報を確認する例が示されました。複数の情報を一つの画面にまとめることで、担当者が環境全体の様子を把握しやすくしています。日常的に確認する情報を集約することは、異常が起きた際に、どこを調べるべきか判断する助けにもなります。

ライセンスも重要な可視化対象です。講演では、利用中のライセンス数や期限に関する情報を扱い、ダッシュボードで確認する仕組みが紹介されました。システムの稼働状況に加えて、利用者が実際にサービスを使うための条件まで把握している点が特徴です。監視対象となるユーザーのリストを更新する運用にも触れられ、収集対象を実態に合わせて維持する必要性がうかがえました。

■ 通知を、確認と対応につなげる

異常を迅速に知るためのアラームは欠かせませんが、通知が多くなると、その内容を確認して対応すること自体が課題になります。講演でも、多数のメール通知を受け取る状況が取り上げられました。情報を集めて通知する仕組みを整えるだけでは、運用上の負担がなくなるわけではありません。

そこで言及されたのが、事前チェックやワークフローの状態確認です。自動化を考える際にも、対象の状態を確かめる仕組みが必要であり、通知から直ちに処理を実行すればよいという単純な話ではありません。また、チームからの連絡や確認を取り入れるフィードバックの流れも紹介されました。監視で得た情報と現場で把握した状況を照らし合わせることが、問題の確認や対応を支えています。

■ 製造を支えるアプリケーション監視の価値

今回の講演が示したのは、監視対象をインフラからアプリケーション、さらに業務の流れへと広げる実践です。データベース、プロセス、ログ、ファイル、ライセンス、ワークフローをそれぞれ確認することで、単一の指標では見えない問題を捉えようとしています。その実現には、Teamcenter の内部構造と運用を理解し、必要な情報を選び取る作業が欠かせません。

ラリーカー製造という現場を支える PLM 環境において、監視は障害を知らせるだけの仕組みではありません。担当者が日々の状態を理解し、見落としやすい問題に気付き、対応へ進むための基盤です。Zabbix の収集・可視化・通知の機能を、対象アプリケーションの特性に合わせて組み合わせることの価値が伝わる事例でした。

おわりに

今回紹介した講演では、大規模なデータ収集を支える性能面の工夫から、日々の運用を効率化する機能、アプリケーションや業務サービスの状態を把握するための監視、さらには AI や外部システムとの連携まで、Zabbix の幅広い活用方法が紹介されました。

毎秒 100 万件の新規監視値を扱うための性能検証では、データの収集や保存の仕組みを適切に調整することの重要性が示されました。また、エージェントやプロキシの設定、通知メッセージの改善といった日々の運用に関わる工夫も取り上げられ、監視環境の規模を拡大することと、扱いやすさを両立するための考え方を知ることができました。

一方、Teamcenter の監視事例や SLA 監視の講演では、インフラの稼働状況だけでなく、アプリケーション内部の処理や業務サービスへの影響まで把握することの重要性が示されました。さらに、収集したデータをレポートや KPI に変換し、外部システムや AI による異常検知に活用する取り組みからは、監視データを運用改善や意思決定に役立てる可能性が見えてきます。

これらの事例から、監視環境を改善するうえでは、単に監視項目を増やしたり、より多くのデータを収集したりするだけでなく、何を把握したいのか、得られた情報を誰がどのように活用するのかを考えることが重要だと感じました。

Zabbix には、データ収集、障害検知、可視化、通知、サービス監視など、さまざまな機能が備わっています。これらを監視対象や運用上の課題に合わせて組み合わせることで、障害の早期発見にとどまらず、日々の運用の効率化やサービスの信頼性向上にもつなげることができます。

Zabbix Summit 2026 で紹介された事例や考え方を参考に、私たちもお客様の環境や課題に応じた監視のあり方を考え、より実用的な監視・運用の実現に取り組んでいきたいと思います。

はじめに

Zabbix Summit は、オープンソースの統合監視ソリューションである Zabbix に関する最新情報や活用事例、技術的な知見が共有されるイベントです。世界各国の Zabbix ユーザーやエンジニア、パートナー企業、開発者などが集まり、Zabbix の最新機能や今後の開発の方向性、実際の運用現場での取り組みについて理解を深める機会となっています。

今回開催された Zabbix Summit 2026 では、Zabbix の最新バージョンに関する情報をはじめ、監視運用の効率化や自動化、生成 AI との連携、オブザーバビリティなど、今後の監視基盤を考えるうえで興味深いテーマが取り上げられました。

本レポートでは、Zabbix Summit 2026 で発表されたセッションの中から、特に注目した内容をピックアップし、技術的なポイントや実際の Zabbix 環境への活用という観点から紹介します。

Zabbix 8.0 が切り拓く Observability の新時代 ― Alexei Vladishev 氏による基調講演

Zabbix Summit 2026 で、Zabbix の創設者である Alexei Vladishev 氏が「Zabbix 8.0: Redefining Observability」と題した講演が行われました。
講演では、Zabbix 8.0 の主要な新機能と性能改善に加え、AI、クラウド、モバイル、Marketplace を含む今後の戦略が紹介されました。
特に印象的だったのは、従来の監視ツールから、システム全体の状況と問題の背景を理解する Observability プラットフォームへ進化させようとする方向性です。

■ オープンソースと統合監視という Zabbix の強み

Alexei 氏は、Zabbix の大きな特徴として、オープンソースであること、さまざまな環境に柔軟に対応できること、監視に必要な機能を統合的に提供することを挙げました。
Zabbix は、OS やネットワーク機器の監視を中心に発展してきましたが、現在ではコンテナ、クラウド、アプリケーション、オンプレミスとクラウドが混在するハイブリッド環境まで対象を広げています。
異なるベンダーの製品を組み合わせて監視基盤を構築する方法もありますが、できるだけ多くの機能を一つの基盤で利用できることは、構成や運用の複雑さを抑えるうえで重要です。
ライセンス料金を課さない方針に加え、公開ドキュメント、公式トレーニング、各種サービスによって利用者を支援する姿勢も強調されました。
セキュリティについては、認証や製品開発・提供プロセスへの対策の組み込みに触れ、機能の豊富さだけでなく信頼性も重視していることが示されました。

■ OpenTelemetry とトレースによる可観測性の拡張

Zabbix 8.0 の重要なテーマの一つが、OpenTelemetry などを通じた新しい種類のデータの取り扱いです。
従来のインフラ監視では、CPU 使用率、メモリ、ディスク、ネットワークの状態といったメトリクスが中心でした。
しかし、複数のサービスが連携するアプリケーションでは、ある処理がどこを通り、どの部分で遅延や障害が発生したかを把握する必要があります。
そこで重要になるのが、リクエストや処理の経路を追跡するトレースデータです。
講演では、こうした情報を Zabbix で収集、保存、可視化する取り組みが説明され、AWS X-Ray にも言及されました。
メトリクス、ログ、トレースを関連付けて扱うことができれば、単に異常を検知するだけでなく、問題がインフラにあるのか、アプリケーションにあるのかを調べる手掛かりが増えます。
Zabbix をインフラ監視だけでなく、アプリケーションの動作を理解するための基盤へ広げる重要な変化と言えます。

■ MCP Server で AI と監視データを接続

もう一つの大きな進化として紹介されたのが、MCP Server への対応です。
MCP Server は Zabbix と AI の間に入る仲介役として機能し、AI から監視情報を参照・活用するための接点になります。
講演では、「今、最も重要な問題は何か」「どのホストに注目すべきか」といった問いを自然言語で投げかける利用方法が例示されました。
これまで監視担当者は、画面を切り替え、条件を指定し、複数の情報を読み解いて状況を把握する必要がありました。
AI との連携が進めば、必要な情報を対話形式で取り出し、調査の出発点を素早く見つけることが期待されます。
Alexei 氏は、特定の AI モデルに固定するのではなく、利用者が適切な AI の仕組みを選べる柔軟性も重視していました。
ただし、AI がすべての判断を自動化するという説明ではなく、監視データをより使いやすくするための新しいインターフェースとして理解することが重要です。

■ 複合イベント処理によってアラートの意味を整理

Complex Event Processing と呼ばれる複合イベント処理も、講演で強調された機能です。
大規模環境では、単一の障害が原因で多数のトリガーや問題イベントが短時間に発生することがあります。
すべてのイベントを個別に確認する運用では、本当に対処すべき問題が大量の通知に埋もれてしまいます。
新しい処理の仕組みでは、イベントの流れやパターンを扱い、関連する事象を整理して重要な情報を浮かび上がらせることを目指しています。
講演では、毎分 100 件を超えるイベントが発生する状況にも触れ、単純なイベント単位のルールを超えた複雑な処理や、プログラムによるパターンマッチングの拡張について説明されました。
監視の価値を、アラートを数多く出すことから、運用担当者が優先順位を判断しやすくすることへ変えていく機能です。

■ 毎秒数百万メトリクスを見据えた性能向上

性能面では、大量の監視データを継続的に処理する環境を想定した改善が紹介されました。
Alexei 氏は、毎秒数百万件規模のメトリクスを扱う事例を挙げ、ボトルネックの解消やストレージ処理の最適化について説明しました。
新しいストレージエンジンへの対応や、高度な圧縮技術によって、データを効率的に保持・処理する方向性が示されています。
CPU やメモリの効率についても改善が語られ、処理によっては大幅な高速化が得られることが強調されました。
ただし、講演中に示された性能値は特定の条件に基づくものと考えられるため、あらゆる環境で同じ改善率が得られると断定することはできません。
大規模な監視基盤ほど、こうした処理効率の向上はインフラコストや拡張性に直結します。

■ 使いやすさを高める UI とビューのカスタマイズ

UI の改善も、日常の運用に直接関わる重要なテーマです。
講演では、画面の一貫性やアクセシビリティの改善に加え、利用者が必要な情報を柔軟に表示するためのカスタマイズ機能が紹介されました。
表示する列の追加や並べ替え、タグやホストのインベントリ情報を利用した列の構成などにより、用途に応じた一覧画面を作成できるようになります。
例えば、データセンター名や機器に関する情報を列として表示すれば、問題の発生場所や対象機器を一覧から把握しやすくなります。
また、データのフィルタ条件と表示方法を保存し、異なる目的に応じて複数のビューを使い分ける考え方も説明されました。
監視データの量が増えるほど、情報の見せ方を利用者自身が調整できることの価値は高まります。

■ Zabbix Cloud と Mobile App による運用の変化

Zabbix Cloud については、監視基盤そのものの保守負担を減らすサービスとして紹介されました。
利用者がセキュリティパッチ、バックアップ、基盤のメンテナンスを細かく管理する必要を減らし、本来の監視業務に集中できることが狙いです。
クラウドから各拠点のインフラを監視する構成や、Zabbix のバージョン対応についても言及がありました。
一方、Mobile App では、重要な問題をプッシュ通知で素早く把握することと、外出先から問題の状態を確認することが主要な利用場面として示されました。
ユーザープロファイルとモバイル端末を関連付ける仕組みにも触れ、日常的な監視業務をデスクトップの外へ広げようとする姿勢がうかがえます。
Cloud と Mobile App は、監視の対象だけでなく、監視サービスの提供方法や利用する場所を変える取り組みです。

■ Marketplace が広げる拡張機能のエコシステム

Marketplace については、Zabbix 向けの追加機能やソリューションを見つけ、共有・入手するための場所として紹介されました。
例えば、新しいレポートや追加モジュールが必要な場合に、コミュニティやベンダーが提供する成果物を利用できるようにする構想です。
無料のものだけでなく、商用の拡張機能も想定されており、開発者が作成した機能を多くの Zabbix ユーザーへ届ける場として期待されています。
個別に作られていた便利な機能が広く流通すれば、利用者は開発の手間を減らせる一方、パートナーや開発者には新たな提供機会が生まれます。
講演では Marketplace に関する別セッションも案内され、利用者からの期待や意見を集めたいという呼びかけがありました。

■ 今後の展望 ― AI を製品と開発プロセスの両方へ

講演の最後には、Zabbix の長期的な方向性として AI のさらなる活用が語られました。
MCP Server による外部 AI との接続に加え、将来的にはテンプレート作成など、Zabbix の機能そのものに AI を組み込む方向性が示されました。
例えば、監視したいデバイスの情報を伝えることで、設定作業を支援するような使い方が考えられます。
また、AI の活用対象は製品機能に限らず、コードの作成やテスト、QA といった開発・品質保証の領域にも広がっています。
これらはすべてが Zabbix 8.0 で完成しているという意味ではなく、今後の開発に向けた戦略的な展望として説明された内容です。

Root Cause Analysis with Complex Event Processing ― CEP による根本原因分析

Kaspars Mednis 氏の講演「Root Cause Analysis with Complex Event Processing」では、Zabbix のイベント相関機能を活用し、大量の障害通知から根本原因を特定するための考え方が紹介されました。
複合イベント処理（ CEP：Complex Event Processing ）を利用した根本原因分析の目的は、単にアラート数を減らすことではなく、原因となる問題と派生的な症状を区別することです。
時間ウィンドウ、キャパシティ、グループ化、相関ルールを適切に設計すれば、複雑な依存関係の保守負担を減らし、障害対応時に注目すべき情報を絞り込めます。
一方で、設定によってイベントの扱いが変わるため、実際の監視環境に合わせて動作を検証することが重要です。

■ 従来のトリガー依存関係の課題

ひとつの障害が複数のサービスに影響すると、根本原因とは別に多数の関連アラートが発生します。

従来はトリガー間の依存関係を定義して対処できましたが、構成が複雑になるほど設定や保守が難しくなります。
講演では、既存の依存関係が機能することを認めながら、イベントの発生状況に応じて柔軟に関連付ける方法が説明されました。

■ 複合イベント処理（ CEP ）によるイベント相関

複合イベント処理（ CEP ）では、まずフィルターで対象イベントを選び、相関ルールを設定します。
ホストグループやタグなどの属性を条件にでき、関連するイベントを同じ処理の対象として扱えます。
相関ルールでは、どのイベントを照合し、一致した場合にどのような操作を行うかを定義します。
この方法により、すべての依存関係を手動で列挙することなく、一定の条件に基づいて問題同士を関連付けられます。

■ 時間ウィンドウとキャパシティ

中心となる概念が、イベントを一定期間保持して照合する時間ウィンドウです。
例えば 10 分間のウィンドウを設定すると、その期間に入ったイベントを条件に従って評価できます。
イベントがいつウィンドウに入り、いつ対象から外れるかによって相関結果が変わるため、継続時間の設定が重要です。
また、ウィンドウに保持するイベント数を制限するキャパシティも設定できます。
講演では、解決済みの問題であってもウィンドウ内に残る間はキャパシティを消費する場合があることが強調されました。
単にアラートが解決したかどうかだけでなく、ウィンドウ内の状態を理解する必要があります。

■ イベントのグループ化

タグなどを利用してイベントをグループ化すると、同じルールを複数の対象に適用しながら、ウィンドウをグループごとに分離できます。
例えばストレージごとにグループを分ければ、異なるストレージの障害を誤って関連付けずに済みます。
複数の一致条件を組み合わせることもでき、イベントの属性や発生順序に応じた処理を構成できます。
なお、相関ルールで処理対象から外すことと、元のアラートそのものを削除することは同じではありません。

■ ポートフラッピングへの適用

具体例として、ネットワークポートがダウンとアップを短時間に繰り返すポートフラッピングが紹介されました。
こうした変化をすべて独立した障害として通知すると、重要な問題が大量のアラートに埋もれてしまいます。
同じポートのイベントを時間ウィンドウで関連付ければ、繰り返し発生する変化をまとめて扱い、不要な通知を抑制できます。

■ 障害の連鎖とログイン失敗

バックアップ失敗など、ひとつの障害が後続の問題を引き起こすケースも取り上げられました。
イベントを関連付け、条件を満たした際に複数の問題をまとめて解決扱いにするなどの処理が考えられます。
また、ログイン失敗が繰り返されるケースでは、ウィンドウ内のイベント数を評価し、代表的なアラートを残して後続通知を抑制する方法が説明されました。

■ 独自ロジックによる拡張

講演では、ウィンドウ内のイベントを数える関数などを使い、条件判定の結果として true または false を返す処理にも言及がありました。
イベントのタグや数値属性を変更したり、複製や破棄などの操作を組み合わせたりすることで、用途に応じた相関ロジックを作成できます。

Zabbix の新たな APM の可能性 ― OpenTelemetry を活用した監視の進化

Zabbix の製品責任者である Martiņš Orinskis 氏は、「Unlocking New APM Power」と題した講演で、OpenTelemetry を活用したアプリケーション監視の新たな可能性を紹介しました。
クラウドネイティブ技術や分散アーキテクチャの普及により、アプリケーションの健全性を把握することは従来以上に難しくなっています。
単純な死活監視や個別の性能指標だけでなく、複数のサービスを横断して状況を理解し、問題の原因を迅速に特定する仕組みが求められています。

■ OpenTelemetry による多様なデータの活用

OpenTelemetry は、メトリクス、ログ、トレースなどのテレメトリデータを共通の仕組みで収集・転送するための技術です。
講演では、OpenTelemetry Protocol を通じて得られるデータには豊富な属性や情報が含まれる一方、そのままでは量が多く、監視に利用しにくい場合があると説明されました。
そこで重要になるのが、データを集約・計算・変換し、運用担当者にとって意味のあるメトリクスに整理することです。
例えば、特定の業務処理に対するリクエスト数や、サービス単位の応答時間などを抽出すれば、アプリケーションの状態を把握しやすくなります。

■ Zabbix Proxy を活用した収集と集約

今回の説明では、Zabbix Proxy を中心に OpenTelemetry のデータを扱う構成が紹介されました。
テレメトリデータを収集する処理と、そこから必要な値を取り出して Zabbix で監視する処理を分けることで、大量の生データをそのまま監視基盤に保存する必要を減らせます。
プロキシ側で集約やクエリを実行し、結果を Zabbix のアイテムとして扱うことで、既存の監視やアラート機能との連携が可能になります。
講演では、テレメトリストレージに対して SQL に似たクエリを実行し、その結果を JSON 形式で受け取り、Zabbix のストレージに保存する流れも説明されました。
これにより、詳細なデータの保管と、日常の監視に必要な指標の管理を役割分担できる構成が示されました。

■ 柔軟な設定と動的な情報の取得

OpenTelemetry を利用するための接続設定については、設定ファイルを使う方法に加え、ユーザーインターフェースから接続を定義する方法も紹介されました。
収集対象やリソース属性、ホストに関連する設定を組み合わせることで、環境に応じた監視を構成できます。
また、データに含まれるサービス名などの属性を利用し、動的に情報を識別することも重要なポイントです。
JSON 形式のデータから必要なフィールドを取り出す機能や、複数の値をまとめて取得する方法についても説明がありました。
こうした仕組みは、サービスや監視対象が頻繁に変化する環境で特に役立つと考えられます。

■ 集約間隔とアラートの設計

講演では、データの集約間隔とアイテムの実行間隔を適切に設定する必要性にも触れられました。
例えば、10 秒ごとにクエリを実行する場合、どの時間範囲のデータを集約するかによって、監視結果に欠落や重複が生じる可能性があります。
短時間のサンプリングで動作を確認しながら、用途に合った集約方法を選ぶことが重要です。
さらに、JSONPath を使ったフィールドの抽出や、取得したデータに基づくトリガーの設定によって、特定の状態を検出してアラートにつなげる考え方が示されました。
一方、JSON データに対する一部の高度な関数や相関処理については、今後の対応が期待される機能として言及されました。

■ APM と従来の監視をつなぐ

今回の講演で印象的だったのは、OpenTelemetry を独立した監視の仕組みとして扱うのではなく、Zabbix が持つ既存の監視機能と組み合わせようとしている点です。
データセンター全体の状態から、個々のサービスや特定のエンドポイントの応答時間まで、対象に応じて監視の粒度を変えることができます。
ログ、トレース、メトリクスを組み合わせて分析することで、単に異常を検知するだけでなく、その背景にある原因を調べるための手掛かりも得られます。
OpenTelemetry から得られる膨大な情報を、実際の運用に役立つ指標へ変換することが、今後の APM における重要なテーマだと感じました。
Zabbix の新しい取り組みは、従来のインフラ監視とアプリケーションの可観測性をつなぎ、より幅広いユースケースへの対応を目指すものといえます。

おわりに

今回の講演からは、Zabbix 8.0 が単なる機能追加版ではなく、監視基盤の役割を広げる重要な節目として位置付けられていることが伝わってきました。
OpenTelemetry やトレースによるデータの拡張、MCP Server を通じた AI 連携、複合イベント処理による情報の整理、大規模環境を支える性能改善は、いずれも現代の複雑なシステム運用に直結するテーマです。
さらに、UI の柔軟性、Cloud、Mobile App、Marketplace の取り組みは、Zabbix を利用する人や提供する企業の裾野を広げるものです。
オープンソースと柔軟性という従来の強みを維持しながら、収集したデータから問題の意味を理解し、迅速な判断につなげる Observability プラットフォームへ進化していくことが、今回の講演の中心的なメッセージだったと感じました。

PostgreSQL 19 で相次いだ機能の差し戻し

PostgreSQL 19 のリリースを目前に控えた9月は、複数の新機能が差し戻し（revert）されるという異例の月となりました。

まず、SQL標準のプロパティグラフ問い合わせ機能である SQL Property Graph Queries (SQL/PGQ) が差し戻されています。この機能では、グラフを構成する頂点や辺、ラベル、プロパティなどをシステムカタログで管理していました。しかし、それに伴って依存関係が複雑化し、グラフ削除後に不要なメタデータが残る問題や、ダンプ・リストア時の問題などが報告されていました。議論では、既存の依存関係管理の仕組みそのものを見直す必要があるのではないかという意見も出て差し戻しとなりました。

また、Temporal Table 機能の一部である UPDATE/DELETE FOR PORTION OF も差し戻されました。この機能はレコードが持つ期間情報の一部分のみを更新または削除するものですが、それによって残りの期間を表す新しい行が発生します。この新しく生成された行が、READ COMMITTED 分離レベルで並行実行される更新処理から適切に認識されず、その結果として更新結果が失われる Lost Update 発生の可能性が受け入れがたい問題として捉えられました。

さらに、外部キー参照整合性チェック高速化機能のうち、複数行をまとめて確認するバッチ処理部分が差し戻されています。外部キー参照整合性チェックの高速化は、チェックを SQL 実行ではなく直接インデックス検索で行うことによる性能改善ですが、複数行をまとめて処理する際のスナップショット取得タイミングや、他の機能との相互作用によって不整合が生じる可能性が指摘されていました。そのためバッチ処理部分が差し戻されましたが、1行単位で実行する高速化部分は維持されています。

このほか、オンラインでデータチェックサムを有効化・無効化する機能についても、コミット後に多数の修正が必要となったことから差し戻しが行われました。

グラフ処理や Temporal Table 機能など、データベースとしての可能性を広げる機能が差し戻しとなったのは残念ではありますが、これら新しい機能実装と、既存機能との相互作用や依存関係管理、並行実行制御といった PostgreSQL の深い部分との関わりが表面化した例として興味深く感じました。

TOAST の改善

一方で、PostgreSQL 20 に向けた開発として、TOAST 関連の改善が進展しています。

TOAST とは PostgreSQL で大きなデータをテーブルに格納するための基盤で、データを圧縮・分割して専用の TOAST テーブルへ格納します。その管理に利用する OID（Object ID） を従来の 4 バイトから 8 バイトへ拡張する機能がコミットされました。

従来の 4 バイトの TOAST OID では、大量のデータを扱うシステムでは枯渇する可能性があり、データ行の挿入時に未使用 OID を探索する必要があり、そのオーバーヘッドによる性能低下も課題となっていました。新しい方式ではテーブル単位のオプションによって 8 バイト OID を利用できるようになり、未使用 OID を探索する必要がなくなることから性能改善も期待されています。

また、TOAST の圧縮方式拡張も議論されています。現在利用できる圧縮方式は pglz と lz4 の2種類のみですが、将来的により多くの圧縮方式を追加できるようにするための基盤整備が提案されています。最初の追加候補としては ZSTD が予定されています。

圧縮プロトコル

通信性能改善に関する提案として、プロトコル圧縮にも進展がありました。

これは、バックエンドからフロントエンドへ送られるデータを圧縮する提案です。過去の議論でカバーする機能を広げすぎて合意に至らなかった反省から、今回は機能を絞る方向で議論が進められています。対象となるのはSELECT や COPY 文で送られる行データで、圧縮方式としては ZSTD のみをサポートする方向で検討されています。また、コネクションプーラとの互換性を維持するため、トランザクション境界で圧縮フレームをリセットする仕組みも議論されています。

UNDO ログエンジン

リカバリ関連では、新しい UNDO ログエンジンの提案がありました。

PostgreSQL は REDO ログ（WAL）を中心とした設計を採用しており、トランザクションの変更を取り消すための UNDO ログは持っていません。そのため、更新・アボートの繰り返しでテーブルやインデックスが膨張したり、クラッシュ時に作成途中のファイルがディスク上に残る（孤立ファイル問題）が課題となっていました。過去にも zheap など UNDO ログベースのテーブルアクセスメソッドの提案がありましたが、今回の提案は新しいテーブルアクセスメソッドから出発するのではなく、まず汎用的な UNDO 基盤を用意しようというアプローチです。

提案では、共通の UNDO 情報は通常の WAL に記録し、アクセスメソッド固有の UNDO 情報は別領域で管理します。また、アボートされたトランザクションや UNDO の進捗を一元管理し、実際の UNDO 処理はバックグラウンドで実行することで、高速なリカバリの実現を目指しています。

まずは UNDO ログを用いた孤立ファイルの削除やアボート済みデータの回収を対象とした機能を先行して実装し、その後に新しいテーブルアクセスメソッドへの応用を検討する構想となっています。新しいテーブルアクセスメソッドから作るのではなく、UNDOログのための新基盤の整備から始めるという方向性は興味深いものに感じました。

ブルームフィルタによるハッシュ結合改善

以前にも紹介した、ブルームフィルタ（Bloom Filter）を利用したハッシュ結合の改善についても引き続き議論が続いています。

これは、ブルームフィルタを利用することで、結合先に存在しない行をスキャン段階で除外できるため、大幅な性能向上が期待できるという提案ですが、9月には、プランナにおけるブルームフィルタ適用後の行数の見積もりについて議論されていました

提案の一つでは、ブルームフィルタを近似的な semi-join （結合先に存在する行だけを残す結合）とみなしてコストベース最適化へ組み込む方法が示されています。これは、SIGMOD 2025 で発表された論文（Including Bloom Filters in Bottom-up Optimization）を参考にしたものです。一方で、コストベースの最適化では正確な行数推定は難しくプラン処理も複雑になるという意見も出されています。その回避策の実例として、実行時に実際のデータを見て振る舞いを動的に調整する SQL Server の実装について紹介した論文（I Can’t Believe It’s Not Yannakakis: Pragmatic Bitmap Filters in Microsoft SQL Server, CIDR 2026）が引き合いに出されていました。そうした懸念から、プランナではブルームフィルタの存在は考慮せず実行時に可能ならば適用する方式を推す声も上がっています。

PostgreSQL のプラン処理にブルームフィルタの存在をどのように組み込むかという議論は、理論と実装をどう結びつけるかという観点からも興味深いと感じており、今後も注目していきたいと思います。

テストデータを少し入れるだけなら、どの型でも問題なく動くように見えるかもしれません。しかし、注文コードの形式が変わったり、金額を集計したり、海外拠点の時刻を扱ったり、決済レスポンスを検索したりすると、型の違いが表面化します。型を選ぶときは、値を保存できるかだけでなく、保存後にどう使うかまで考えます。

この記事は、SQLの基本を理解し、これからテーブルを設計する方に向けた入門向け記事です。架空の注文管理テーブルordersを例に、文字列、数値、日付時刻、JSONの型を用途別に検討します。型選びに関わる性質と判断理由に絞って説明します。

例では、注文コード、単価、数量、注文日時などを保存します。まずテーブルを定義し、各列の型を用途に照らして確認します。

この最初の定義には、後で見直す候補としてdouble precisionとjsonをあえて含めています。以降の章で、金額の正確さやJSON検索の必要性に応じて、型を変更する条件を確認します。

CREATE TABLE orders (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY -- 注文を一意に識別するID。値はPostgreSQLが自動で採番する。
  , order_code varchar(16) NOT NULL                  -- 注文コード。最大16文字の文字列を必ず入れる。
  , customer_memo text                               -- 顧客からのメモ。業務上の長さ制限を設けず、入力は任意。
  , unit_price numeric(12, 2) NOT NULL               -- 商品1個あたりの単価。全体で12桁、小数点以下2桁。
  , quantity integer NOT NULL                        -- 注文数量。整数値を必ず入れる。
  , total_amount double precision NOT NULL           -- 注文金額の合計。必ず入れる。
  , ordered_at timestamp without time zone NOT NULL  -- 注文日時。必ず入れる。
  , payment_payload json                             -- 決済サービスなどから返されたJSON形式のデータ。
);

1. 文字列型は上限と条件の表し方で選ぶ

1.1. char(n)を選ぶ場面は限られる

注文コードのように形式が決まった文字列には、固定長のchar(n)も候補に見えます。ただし、char(n)は入力が指定した長さに満たない場合、末尾に空白を補います。また、char同士の比較では末尾の空白を無視します。そのため、末尾の空白を値の一部として区別したい列には向きません。

CREATE TEMP TABLE order_code_char (
  code char(5) NOT NULL
);

INSERT INTO order_code_char VALUES ('hi');

SELECT code, char_length(code), octet_length(code), code = 'hi   ', code = 'hi'
FROM order_code_char;
 code  | char_length | octet_length | ?column? | ?column?
-------+-------------+--------------+----------+----------
 hi    |           2 |            5 | t        | t
(1 row)

この例では、'hi'の末尾に3つの空白を補ってchar(5)の幅で保存しています。char_length(code)は末尾の空白を数えないため2を返しますが、octet_length(code)は、このASCII文字列では5を返します。空白を含む'hi 'との比較も、含まない'hi'との比較もtrueです。固定長を指定しても、入力された文字列をそのまま区別して保存できるわけではありません。

性能面でも、char(n)を選ぶ利点はありません。公式文書の「8.3. 文字型」によると、PostgreSQLのchar(n)には固有の性能上の利点がありません。空白埋めで保存領域が増えるため、char(n)、varchar(n)、textの中では通常最も遅い型です。新規設計ではchar(n)を避け、最大長を制限するならvarchar(n)やCHECK制約を検討します。

1.2. varchar(n)は文字数の上限を型に記せる

orders.order_codeには、最大16文字を保存できるvarchar(16)を指定しています。varchar(16)は、char(n)のように後ろに空白文字を補わず、指定した文字列をそのまま保存します。初期の注文コードが次の形式なら15文字なので、後ろに空白文字が付くことなく保存できます。

CREATE TEMP TABLE orders_code_varchar (
  order_code varchar(16) NOT NULL
);

INSERT INTO orders_code_varchar VALUES ('OD-000000000001');

発番側の仕様変更で注文コードに日付が加わると、上限を超える場合があります。次の値は18文字なので、同じ列には保存できません。

INSERT INTO orders_code_varchar VALUES ('OD-20260801-000001');
ERROR:  value too long for type character varying(16)

これはvarchar(n)の長さ制限によるエラーです。公式文書の「8.3. 文字型」では、character varying(n)、つまりvarchar(n)は最大n文字を保存できる型と説明されています。通常の挿入では、超過分がすべて空白の場合を除き、上限を超える入力はエラーになります。ここでいうnはバイト数ではなく文字数です。

varchar(n)を使うときは、現在のデータが収まるかに加えて、上限の根拠を確認します。注文コードの仕様が変わったら、発番側の変更に合わせてデータベース側の上限も見直します。

1.3. 長さの上限は型か制約で表す

注文コードの上限が業務仕様として「最大18文字」と決まっているなら、varchar(18)を使えます。型定義から最大長が分かり、上限を超える入力はデータベースが拒否します。上限を変える場合は、列の型定義を変更します。

文字列型と業務上の条件を分けて定義するなら、textとCHECK制約を組み合わせる方法もあります。CHECK制約は、条件式がFALSEになる値を拒否します。条件式がNULLになる値は通過するため、NULLも拒否する場合はNOT NULL制約を併用します。次の定義では、text型の注文コードをOD-で始まる18文字以下の値に制限しています。

CREATE TEMP TABLE orders_code_text (
  order_code text NOT NULL,
  CONSTRAINT orders_code_format_check CHECK (
    order_code LIKE 'OD-%'
    AND char_length(order_code) <= 18
  )
);

CHECK制約では、長さと接頭辞の条件を同時に定義できます。上限を変えるときは、列の型を維持して制約を変更します。長さだけを型に記すならvarchar(n)、長さを含む業務条件をまとめて管理するならtextとCHECK制約、というように条件の表し方で選べます（CHECK制約）。

この使い分けは、短い文字列にはvarchar(n)、長い文字列にはtextという性能上の区別ではありません。公式文書の「8.3. 文字型」によると、長さ制限の検査や空白埋めの負担を除けば、文字列型の間に性能差はありません。orders.customer_memoのように業務上の長さ制限がない列には、textを使えます。

1.4. 保存できる文字列でもB-treeインデックスに入らない場合がある

長い文字列を保存できることと、その値全体をインデックスのキーにできることは別です。たとえばorders.customer_memoをtextで保存できても、その列にB-treeインデックスを作成できるとは限りません。B-treeは等価比較や範囲検索などに使うインデックスですが、1件のインデックスエントリにはサイズ上限があります。

PostgreSQLは、テーブルやインデックスをページ（データを格納する単位）に分けて管理します。標準的なページサイズは8 KiBです。公式文書の「B-treeインデックス」によると、1つのインデックスエントリは、1ページのおよそ3分の1（8 KiBのページでは約2.7 KiB）を超えられません。TOASTによる圧縮が適用される場合は、圧縮後のサイズが制限の対象です。そのため、テーブルには保存できても、値全体をキーにするとINSERTやCREATE INDEXがエラーで失敗します。値を切り詰めて登録することはありません。

たとえば、圧縮されにくい文字列を保存してからB-treeインデックスを作成すると、次のようなエラーが発生します。エラーメッセージのbuffer pageは、上述のページを指しています。

CREATE TEMP TABLE long_memo (
  memo text
);

INSERT INTO long_memo
SELECT string_agg(md5(random()::text), '')
FROM generate_series(1, 200);

CREATE INDEX ON long_memo (memo);
ERROR:  index row size 6416 exceeds btree version 4 maximum 2704 for index "long_memo_memo_idx"
DETAIL:  Index row references tuple (0,1) in relation "long_memo".
HINT:  Values larger than 1/3 of a buffer page cannot be indexed.
Consider a function index of an MD5 hash of the value, or use full text indexing.

この例では、文字列自体はtext列に保存できますが、値全体をB-treeのキーにできないため、CREATE INDEXが失敗しています。既にインデックスがある場合は、同じ値をINSERTした時点でインデックスへの追加に失敗します。INSERT文はエラーで取り消されるため、テーブルに行だけが残ることもありません。この単一列のtextインデックスでは、サイズ制限を回避するために値を途中で切り詰めて登録することはありません。切り詰めた部分だけを使って、異なる値を同一視する動作もありません。

この制限はtextだけでなく、大きなvarchar(n)にも当てはまります。長い文字列を検索するときは、検索方法に合ったインデックスを選びます。単語単位の検索には全文検索とGINインデックス、完全一致検索にはハッシュ値を使った式インデックスなどが候補です。ハッシュ値には衝突の可能性があるため、利用者はハッシュ値の条件に加えて元の値との比較条件も検索に含めます。PostgreSQLは、指定された元の値との比較条件を評価し、ハッシュ値が一致した候補から検索対象を絞り込みます。

2. 数値型は必要な正確さと値の範囲で選ぶ

2.1. double precisionは2進数で表せる値しか正確に扱えない

金額の計算や比較を10進数の規則どおりに行うなら、double precisionは使いません。冒頭のorders.total_amountは、必要な桁数を指定したnumericに変更します。一方、測定値や統計計算のように近似値を許容し、計算速度や表現できる値の範囲を優先する用途では、double precisionを使えます。

double precisionは小数を扱えますが、2進数で有限桁に表せない値は近似値になります。税率や割引率を使って金額を計算し、小数点以下まで正確に扱う場合には、この性質が問題になります。

numericとdouble precisionの違いは、次の計算で確認できます。どちらも0.1 + 0.2が0.3と等しいかを比較しています。

SELECT 0.1::numeric + 0.2::numeric = 0.3::numeric AS numeric_equal;
 numeric_equal
---------------
 t
(1 row)

SELECT 0.1::double precision
     + 0.2::double precision = 0.3::double precision AS double_equal;
 double_equal
--------------
 f
(1 row)

numericではtrue、double precisionではfalseになります。0.1は2進数で有限桁に表せないため、double precisionでは近似値として扱われます。一方、numericは10進数の値を正確に扱うため、この計算では期待どおりの比較結果になります（浮動小数点数データ型）。

整数だけなら、double precisionでも−2の53乗から2の53乗までの整数をすべて正確に保存できます。正数の上限は約9,000兆です。この範囲の金額を1円単位で保存するだけなら、浮動小数点表現による誤差は生じません。また、0.5のように2進数で正確に表せる小数もあります。ただし、税率や割引率を使った計算には、0.1のように近似値になる小数が含まれることがあります。整数を正確に保存できても、その後の計算まで正確とは限りません。

0.1のように2進数で有限桁に表せない小数が計算に含まれると、その値は近似になります。そのため、金額を10進数の規則で計算・比較し、丸めを管理したい要件にはdouble precisionは向きません。orders.total_amountにはnumericを使います。

2.2. 金額にはnumeric、個数には整数型を使う

10進数として正確に扱う金額には、必要な桁数を決めてnumericを使います。numeric(precision, scale)のprecisionは全体の桁数、scaleは小数点以下の桁数です。orders.unit_priceのnumeric(12, 2)は、全体で12桁、小数点以下2桁を指定しています。指定より多い小数桁の入力は、まず2桁に丸められます。丸めた後の整数部が10桁を超える値は保存できません。orders.total_amountにも同じ考え方を使えますが、合計額に必要な桁数は単価とは分けて確認します。

金額を常に円単位の整数として扱うなら、integerやbigintに保存する設計も選べます。この場合も、税率や割引率の計算で小数が出たとき、どの時点で丸めるかを決めます。orders.quantityのような個数や回数には整数型を使い、想定する値の範囲に応じてintegerかbigintを選びます。

近似値を許容できる値には、double precisionを検討します。測定値や統計計算の結果など、10進数としての厳密な一致より計算速度や表現できる値の範囲を優先する用途です。小数を含むかどうかだけでなく、どの程度の正確さが要るかでnumericと使い分けます。

2.3. 新規設計ではmoney型よりnumericを優先する

金額を保存する型にはmoneyもありますが、新規設計ではnumericを優先します。moneyの表示形式や小数部の精度は、データベースのlc_monetary設定に依存します。設定が異なるデータベースへダンプをリストアすると、ダンプに含まれるmoneyの文字列表現をリストア先のlc_monetaryで解釈できず、読み込みに失敗することがあります。読み込みに成功しても、表示形式や小数部の扱いが変わる可能性があります。また、moneyを整数で割った結果は、表現できない小数部を0方向へ切り捨てます。負数の場合も、絶対値が小さくなる方向です。そのため、moneyはデータベースの設定と、演算に組み合わせる型の規則を意識して使う必要があります（通貨型）。

moneyは既存スキーマとの互換性など、明確な理由がある場合に検討します。通貨記号を含む表示が必要なら、numericの値をto_charで整形できます（データ型書式設定関数）。たとえば、to_char(unit_price, 'L999G999G999G990D00')で通貨記号、桁区切り、小数点以下の表示形式を指定できます。ordersの金額列では、保存したnumericの値を計算や比較に使い、画面に表示するときだけto_charで表示用の文字列に変換します。

3. 日付時刻型は保存したい時刻の意味で選ぶ

orders.ordered_atの型を選ぶには、注文日時として何を記録するのかを決めます。受信した表記をそのまま残すのか、特定の地域の日付と時刻を記録するのか、注文が起きた一瞬を記録するのかで選択が変わります。ここでは文字列型、timestamp without time zone、timestamp with time zoneを比較します。

3.1. 受信した表記を残すなら文字列型を選べる

受信した表記をそのまま残す必要があるなら、文字列型を選べます。UTCとの時差を表すオフセットやタイムゾーン名、部分的な日時、仕様外の値も、監査記録として保存できます。PostgreSQLや、JDBCやODBCなどのデータベースドライバに日時として解釈・変換させず、アプリケーション側だけで解釈する方針にも合います。

ただし、文字列型では日時としての妥当性は保証されません。データベースで日時の範囲検索や演算をするなら、日付時刻型を使います。検索と受信原文の保存の両方が必要なら、検索用の日付時刻型列と原文用の文字列列を分けます。

文字列の並び順を日時順として使うには、入力形式と照合順序（文字列比較の規則）を統一します。たとえば日付をYYYY-MM-DDにそろえ、桁数、精度、表記規則を固定すれば、文字列の順序を日付順として利用できます。ただし、異なるタイムゾーンの日時を同じ列に保存すると、表記上の順序と実際の時系列が一致しない場合があります。形式と照合順序を統一するだけで目的を満たせるか確認が必要です。

3.2. timestamp without time zoneは時差を変換しない

orders.ordered_atに指定したtimestamp without time zoneは、日付と時刻を保存しますが、タイムゾーン情報は持ちません。タイムゾーン付きの文字列を入力しても、時差の部分は無視されます。次の例では、同じ入力をtimestamp with time zoneにも保存し、セッションのタイムゾーンを変えて表示を比較します。

SET TIME ZONE 'Asia/Tokyo';

CREATE TEMP TABLE orders_time (
  ts_without timestamp without time zone,
  ts_with timestamp with time zone
);

INSERT INTO orders_time VALUES
('2026-07-01 09:00:00+09', '2026-07-01 09:00:00+09');

SELECT ts_without, ts_with FROM orders_time;
     ts_without      |        ts_with
---------------------+------------------------
 2026-07-01 09:00:00 | 2026-07-01 09:00:00+09
(1 row)

SET TIME ZONE 'UTC';

SELECT ts_without, ts_with FROM orders_time;
     ts_without      |        ts_with
---------------------+------------------------
 2026-07-01 09:00:00 | 2026-07-01 00:00:00+00
(1 row)

ts_withは、Asia/Tokyoでは09:00:00+09、UTCでは00:00:00+00と表示されます。一方、ts_withoutはどちらでも09:00:00です。timestamp without time zoneでは、入力に含まれる+09を使った変換も、表示先のタイムゾーンに合わせた変換も行われません。

timestamp without time zoneが適するのは、特定の地域の日付と時刻そのものを扱う場合です。たとえば、店舗の営業開始日時やシフト開始日時なら、timestamp without time zoneを検討できます。その場合は、どの地域の日時かを店舗や拠点の情報と一緒に管理します。注文が実際に起きた時点を複数の地域から比較する用途には、次のtimestamp with time zoneが適しています。

3.3. timestamp with time zoneは同じ一瞬を保存する

timestamp with time zoneは、タイムゾーンを考慮して日時を扱います。明示的なタイムゾーンを含む入力はUTCに変換して保存し、出力時にはセッションのTimeZoneに合わせて表示します。入力時のタイムゾーン名や+09という指定自体は保存しません。

注文受付時刻、決済完了時刻、ログ発生時刻のように、同じ一瞬を複数の地域から比較するなら、timestamp with time zoneが適しています。orders.ordered_atをこの用途に使うなら、timestamp without time zoneから変更する候補になります。前節の例で表示が変わったのは、保存した一瞬はそのままに、表示先のタイムゾーンに合わせて変換したためです。

ただし、タイムゾーンのない入力をtimestamp with time zoneに渡すと、セッションのTimeZoneで解釈されます。アプリケーションの接続設定、データベースドライバによる日付時刻型への変換、取得後の表示設定が一致しないと、意図しない時刻として扱われる可能性があります。入力にタイムゾーンを含めるか、セッションのTimeZoneを固定するかを決め、取得後の表示先も明確にします。

保存したい値ごとの選択肢をまとめます。日付時刻型の仕様は、公式文書の「日付/時刻データ型」と「日付/時刻の入力」を参照してください。

4. JSON型は原文の保持と検索の必要性で選ぶ

4.1. text、json、jsonbは保存後の用途が異なる

orders.payment_payloadには、決済サービスから返されたJSON形式のデータを保存します。保存先にはtext、json、jsonbがあり、受信内容をどこまでそのまま残すか、保存後にどう検索するかで選びます。

textはJSONとして検証しないため、JSONとして不正な文字列も保存できます。NUL文字だけは保存できません。これは、PostgreSQLのtext型自体がNUL文字を保存できないためです。実装上のサイズ上限は約1GBです。JSONとしての妥当性を検証せず、受信内容を残すことが目的なら候補です。

jsonは入力がJSONとして正しいことを検証し、入力されたテキストを保存します。空白、キーの順序、重複キーも保持します。冒頭の定義のようにpayment_payloadをjsonにすると、JSONとして検証しながら受信時の表記を残せます。

jsonbは入力を解析し、分解した形式で保存します。そのため、保存後の検索や比較に向いています。入力時に変換が必要ですが、GINインデックスも利用できます。一方、空白やキーの順序は保持されず、重複キーは最後の値だけが残ります。次のSQLで、重複キーの扱いを比較できます。

SELECT '{"a": 1, "a": 2, "active": false}'::json;
               json
-----------------------------------
 {"a": 1, "a": 2, "active": false}
(1 row)

SELECT '{"a": 1, "a": 2, "active": false}'::jsonb;
            jsonb
---------------------------
 {"a": 2, "active": false}
(1 row)

jsonでは2つのaが入力どおりに残りますが、jsonbでは最後の値である2だけが残ります。受信時の表記を保持するならjson、JSONとしての検証もせず文字列を残すならtext、JSONの内容を検索・比較するならjsonbを選びます。

4.2. JSONのキーや値を検索するならjsonbを使う

決済レスポンスのトップレベルにerror_codeキーがある注文を調べるなら、orders.payment_payloadをjsonbにする方法があります。冒頭のテーブル定義どおり列がjson型の場合、次の検索を実行するとエラーが発生します。?演算子はjsonb型に対して定義されているためです。

SELECT id
FROM orders
WHERE payment_payload ? 'error_code';
ERROR:  operator does not exist: json ? unknown
LINE 3: WHERE payment_payload ? 'error_code';
                              ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.

列をjsonbに変更すると、同じ条件でキーの有無を調べられます。

ALTER TABLE orders
  ALTER COLUMN payment_payload TYPE jsonb
  USING payment_payload::jsonb;

SELECT id
FROM orders
WHERE payment_payload ? 'error_code';
 id
----
(0 rows)

jsonやtextで保存し、検索のたびにjsonbへ変換する方法もあります。ただし、変換が必要になり、インデックスも検索式に合わせて定義しなければなりません。

検索量が増えたら、jsonb列へのGINインデックスも検討します。GINは、JSONのキーや値などを使った検索に利用できるインデックスです。標準のGIN演算子クラスでは、キーの存在、包含、JSONPathによる検索などを扱えます。詳しくは公式文書の「JSONデータ型」と「jsonbインデックス」を参照してください。

5. まとめ: 列の用途から型を決める

ordersの各列を見直すと、値の形式だけでは型を決められないことが分かります。注文コードには長さの上限、金額には計算の正確さ、注文日時にはタイムゾーンの扱い、決済レスポンスには原文の保持と検索方法を考える必要があります。

文字列では、最大長を型に記すならvarchar(n)、業務条件を制約で管理するならtextとCHECK制約を検討します。char(n)は空白埋めと比較規則に注意が必要で、性能上の利点もないため、新規設計で選ぶ場面は限られます。また、長い文字列を保存できても、値全体をB-treeインデックスのキーにできるとは限りません。

数値では、10進数の正確さが必要ならnumeric、整数で足りるなら値の範囲に応じてintegerかbigintを選びます。double precisionは近似値を許容できる用途に使い、金額では丸める時点と規則も決めます。moneyは設定や演算規則に依存するため、新規設計で使う場合は注意が必要です。

日付時刻では、同じ一瞬を扱うならtimestamp with time zone、特定の地域の日付と時刻を扱うならtimestamp without time zoneを検討します。受信した表記を残すために文字列型を選ぶこともできますが、その場合は日時としての妥当性や比較方法を別途管理します。

JSONでは、受信文字列を検証せずに残すならtext、JSONとして検証して入力テキストを保持するならjson、内容を検索・比較するならjsonbが候補です。決済レスポンスを記録として残すのか、内容を使って注文を検索するのかで、適する型が変わります。

テーブルを設計するときは、列ごとに保存する値と用途を確かめます。拒否する入力、必要な計算、検索条件が明確になれば、型を選ぶ理由も定まります。