PostgreSQL 19ベータ1の新機能と既定値の変更

PostgreSQL 19ベータ1の新機能と既定値の変更

作成日:
読了:6
更新日:
この記事を読む人におすすめPR / Amazonアソシエイト

当サイトは Amazon.co.jp を宣伝しリンクすることで紹介料を得る手段を提供する、Amazonアソシエイト・プログラムの参加者です。価格・在庫はリンク先の最新情報をご確認ください。

PostgreSQL 19 Beta 1が2026年6月4日に公開されました。コア機能は出そろっていますが本番利用は想定されておらず、追加のベータとリリース候補を経て、正式版は2026年9月から10月ごろに出る見込みです。PostgreSQL 18で入った非同期I/Oの土台を引き継ぎ、その上に機能を積み増した版にあたります。

開発者がすぐ使える新機能

ON CONFLICT DO SELECTは、競合した行をそのまま取り出せるようにします。これまで「あれば取得、なければ挿入」を1文で書こうとすると、競合時にDO UPDATEでダミーの更新をかけ、不要な不可視タプルを生んでいました。新しい構文はその回避策を置き換えます。

競合行をそのまま返す
INSERT INTO users (email, name) VALUES ('a@example.com', 'A')
ON CONFLICT (email) DO SELECT
RETURNING *;

REPACKは、テーブルの再編成を1つのコマンドにまとめます。従来VACUUM FULLCLUSTERに分かれていた処理を統合し、CONCURRENTLYを付ければ排他ロックを取らずに再編成できます。使うレプリケーションスロット数はmax_repack_replication_slotsで制御します。

排他ロックなしの再編成
REPACK my_table CONCURRENTLY;

COPY TOがJSONを直接出力できるようになりました。既定では1行1オブジェクトのNDJSON形式で、FORCE_ARRAYを付けると配列として出します。

JSONでのエクスポート
COPY my_table TO STDOUT WITH (FORMAT json);
COPY my_table TO STDOUT WITH (FORMAT json, FORCE_ARRAY);

SQL/PGQも入りました。これはSQL:2023のプロパティグラフクエリで、既存のリレーショナルテーブルに対してGRAPH_TABLE句でパターンマッチングを書けます。専用のストレージへ移す必要はなく、テーブルをグラフとして問い合わせます。

運用と性能にかかわる変更

autovacuumが並列ワーカーを使えるようになりました。autovacuum_max_parallel_workersでインデックス処理の並列度を決めます。並列化はメモリを食うため、消費量がワーカー数とmaintenance_work_memの積で膨らむ点に注意がいります。どのテーブルを優先して掃除するかは、新しいビューpg_stat_autovacuum_scoresでスコアを確認できます。

非同期I/Oは、PostgreSQL 18のio_method=workerを土台に、負荷へ応じてワーカー数を自動で増減するようになりました。io_min_workersio_max_workersなどのパラメータで範囲を決めます。実行計画ではEXPLAIN ANALYZEのI/O統計から非同期I/Oの様子を読めます。

外部キー制約のチェックは、INSERT時の性能が公式ニュースで最大2倍になったとされています。データチェックサムは、クラスタを止めて初期化し直さなくても、オンラインで有効化と無効化を切り替えられるようになりました。

プランナーの判断を安定させたい場合は、新しいcontrib拡張のpg_plan_adviceを使います。SQLにコメントを書く代わりにGUC設定で指示を与え、アプリのコードを変えずに実行計画を固定できます。

プラン安定化の拡張
CREATE EXTENSION pg_plan_advice;

既定値と互換性の変更

メジャー更新なので、既定値の変更と削除がいくつかあります。とくにJITが既定で無効になった点は、分析系の重いクエリで性能差として現れることがあるので、必要なら明示的に有効化します。

項目変更影響
jiton から off分析クエリで遅くなる場合がある。必要時に SET jit = on
default_toast_compressionpglz から lz4新規TOASTデータがlz4圧縮になる。既存データは不変
max_locks_per_transaction64 から 128ロック構造の変更による既定の引き上げ
log_lock_waitsoff から onロック待ちが自動でログに残る
RADIUS認証削除利用中なら別の認証方式へ移行が必要
inet / cidr の既定opclassGiSTへ変更該当インデックスがあると pg_upgrade が失敗する
C言語のビルド要件C99 から C11拡張機能の再コンパイルが必要

このほか、standard_conforming_stringsがサーバー側で強制され、MULE_INTERNALエンコーディングが廃止されました。データベース名やロール名に改行文字を含むクラスタはpg_upgradeに失敗するため、事前に確認します。アップグレードはpg_dumpallによるダンプとリストア、pg_upgrade、論理レプリケーションのいずれかで行います。

試すときの前提

Beta 1は本番向けではありません。正式版までに仕様が動く余地があり、既定値の変更や削除も含むため、検証は新しい環境で行います。手元のアプリを移すときは、JITの無効化やTOASTの圧縮方式の変更が性能に与える影響を測り、pg_upgradeが失敗する条件に当たっていないかを先に確かめておきます。

外部キーチェックの高速化の具体的な実装内容や、I/Oワーカーの既定値といった細部は、リリースノートに数値が明示されていない部分もあります。本番採用の判断材料にするなら、正式版のリリースノートで確定値を確認してください。

参考

トランザクションとACID・分離レベル入門 - dirty read / phantom と PostgreSQL・MySQLの違い

トランザクションとACID・分離レベル入門 - dirty read / phantom と PostgreSQL・MySQLの違い

13

データベースのトランザクションを実務目線で整理します。ACID(原子性・一貫性・分離性・永続性)の意味、BEGIN/COMMIT/ROLLBACKの基本、4つの分離レベル(READ UNCOMMITTED / READ COMMITTED / REPEATABLE READ / SERIALIZABLE)と、各レベルで起き得る異常(dirty read・non-repeatable read・phantom read)の対応関係を表で確認します。さらにPostgreSQLのデフォルトはREAD COMMITTED、MySQL InnoDBのデフォルトはREPEATABLE READという製品差や、PostgreSQLではREAD UNCOMMITTEDがREAD COMMITTED扱いになる点まで、PostgreSQL・MySQL公式を一次ソースにまとめます。

ページネーション設計 - オフセット方式とカーソル(キーセット)方式の使い分け

ページネーション設計 - オフセット方式とカーソル(キーセット)方式の使い分け

8

一覧の分割表示(ページネーション)を実務目線で整理します。LIMIT/OFFSET によるオフセット方式の利点(任意ページへジャンプ・総件数)と欠点(大きな OFFSET で遅い・挿入や削除でページずれ)、前回の最後の行を基準にするカーソル/キーセット方式の利点(大規模でも高速・安定)と欠点(任意ジャンプ不可・総ページ数が出しにくい)、複合キーのタイブレーク、不透明カーソルと API レスポンス設計(next_cursor / has_more / GraphQL Relay)、そして使い分けと落とし穴まで、PostgreSQL 公式・Use The Index, Luke・Stripe・Slack を一次ソースにまとめます。

データベースインデックス入門 - B-treeの仕組みと、効くクエリ・効かないクエリ

データベースインデックス入門 - B-treeの仕組みと、効くクエリ・効かないクエリ

10

データベースのインデックスを実務目線で整理します。フルスキャンとの違い、B-tree インデックスがなぜ速いのか、等価・範囲・前方一致・ORDER BY・JOIN で効く理由、複合インデックスの左端プレフィックス、カバリングインデックス(index-only scan)、列に関数を使うと効かない・前方ワイルドカード LIKE が効かないといった落とし穴、書き込みコストやストレージのトレードオフ、InnoDB のクラスタ化インデックスと PostgreSQL の違い、EXPLAIN の読み方まで、PostgreSQL・MySQL 公式と Use The Index, Luke を一次ソースにまとめます。