【テクニカル・上級編】シーケンス操作関数 – PostgreSQL

PostgreSQLのシーケンス：その「便利さ」の裏側に潜む設計の深淵

PostgreSQLを長く触っていると、`SERIAL`型や`IDENTITY`列を当たり前のように使うようになる。だが、その裏で黙々と値を吐き出し続ける「シーケンス」という存在について、どれほど深く考えているだろうか。

単なる「連番生成機」として片付けてしまうには、この仕組みはあまりに奥が深い。今日は、`nextval()`、`currval()`、そして`setval()`といった、一見すると地味な関数たちが、内部でどのように振る舞い、そして我々のパフォーマンスをどう左右するのかを掘り下げていきたい。

—

1. アトミックな連番の裏側：WALと競合の真実

まず、頭に入れておくべき大前提がある。シーケンス操作は、トランザクションのACID特性の対象外だ。

`nextval()`をコールした瞬間、たとえそのトランザクションが後にロールバックされたとしても、シーケンスの値は戻らない。これはPostgreSQLがパフォーマンスのためにあえて選んだ設計だ。もしシーケンスがトランザクションと密結合していたら、高負荷なシステムではシーケンス自体が強烈なボトルネックとなり、データベース全体がロック待ちで麻痺してしまうだろう。

内部的には、`nextval()`は軽量なロック（LWLock）を使用して値をインクリメントし、即座にメモリ上の状態を更新する。この設計により、我々は高いスループットを享受できている。だが、裏を返せば「連番に欠番が生じること」はPostgreSQLにおける正常な動作なのだ。

2. 意外な落とし穴：`currval()`のセッション依存性

初心者がよくハマるのが、`currval()`の使い方だ。

SELECT currval(‘my_seq’);

この関数は「現在のセッションで、最後に実行した`nextval()`の値」を返す。ここで重要なのは「現在のセッション」というキーワードだ。コネクションプーラーを使っている環境で、期待した値が返ってこなかったり、あるいは全く別のトランザクションの値を取得して混乱したりする事故を何度見てきたことか。

並行実行されるアプリケーション環境において、`currval()`に依存したロジックを組むのは地雷原を歩くようなものだ。基本的には`INSERT … RETURNING id`構文でIDを回収する。これがPostgreSQLにおける「モダンで安全な作法」であることは、改めて強調しておきたい。

3. `setval()`という劇薬

データのマイグレーションや、外部システムからのデータインポート時に避けて通れないのが`setval()`だ。

「インポートしたデータの最大値に合わせてシーケンスを修正する」といった作業で多用するが、ここには注意点が二つある。

is_called フラグ: `setval(regclass, bigint, boolean)` の第三引数。これを`true`にすれば、次の`nextval()`はその値の「次」から始まる。`false`にすれば、その値が「次」に返される。この挙動の取り違えは、本番環境でプライマリキーの重複エラーを引き起こす典型的な原因だ。
キャッシュの不整合: シーケンスを作成する際、`CACHE`値を大きく設定していないだろうか？ `setval()`はメモリ上のキャッシュを更新するが、複数ノードや複雑なレプリケーション構成下では、キャッシュの状態を完全に同期させるのが難しいケースがある。

4. パフォーマンスのボトルネックをどう見極めるか

高負荷なシステムで「シーケンスが遅い」と感じる場面があるなら、まずは`pg_stat_sequences`を確認してほしい。

もし、特定のシーケンスに対するアクセスが異常に集中し、かつCPUリソースが飽和しているなら、それは`CACHE`設定を見直すサインだ。デフォルト値の`1`は、安全だが毎回ディスク（WAL）への書き込みを誘発する。これを例えば`100`や`1000`に増やすだけで、ロックの衝突回数は劇的に減り、TPS（秒間トランザクション数）は見違えるほど改善するはずだ。

ただし、`CACHE`を大きくしすぎると、DB再起動時に「値の飛び」が大きくなる。ビジネス上の要件として「連番の連続性」が重要なのか、それとも「システムの応答性」が重要なのか。このトレードオフを判断することこそが、熟練エンジニアの腕の見せ所だ。

—

最後に：ツールとしてのシーケンスを愛する

シーケンスは、PostgreSQLという堅牢な要塞の中で、最もシンプルでありながら、最も「高負荷への耐性」を問われるコンポーネントの一つだ。

安易にシーケンスの挙動に文句を言う前に、まずはその背後にある「なぜこのような設計になっているのか」という意図を汲み取ってみてほしい。そうすれば、シーケンスは単なる「ID生成器」から、パフォーマンスを最適化するための「強力な武器」へと姿を変えるはずだ。

さて、今日もまた、データベースのログを眺めながら、より高効率なスキーマ設計について考えるとしようか。