【テクニカル・上級編】宣言的パーティショニング – PostgreSQL

宣言的パーティショニングの「深淵」—— PostgreSQLの物理レイアウトを制御する技術

PostgreSQLを長く触っていると、ある時点で必ず「数億行のテーブル」という壁にぶつかります。単一のB-treeインデックスがメモリに乗らなくなり、バキュームのたびにI/Oが悲鳴を上げる。そんな時、多くのエンジニアがたどり着くのが「宣言的パーティショニング」です。

PostgreSQL 10で導入されてから数年、今やこれは単なる「大規模データの整理術」を超え、アーキテクトが必須で習得すべき「物理設計の武器」となりました。今回は、ドキュメントに書かれている表面的な使い方ではなく、その内部構造と、現場で踏みがちな地雷について、少し深掘りして話しましょう。

—

1. 宣言的パーティショニングの内部アーキテクチャ

PostgreSQLの宣言的パーティショニングは、`inheritance`（継承）を用いた古い手法とは根本的に異なります。最も重要な違いは、「プランナがパーティション構成を深く理解している」という点です。

内部的には、パーティションテーブルは「メタデータとしての親」であり、個々のパーティションは「独立したテーブル」として管理されます。ここで注目すべきは、プランナが実行する「パーティション・プルーニング（Partition Pruning）」という挙動です。

静的プルーニング: クエリのWHERE句が定数で与えられた場合、プランナはコンパイル時に不要なパーティションを完全に無視します。これはコストゼロの最適化です。
動的プルーニング: 実行時に結合（JOIN）条件やパラメータからパーティションが特定される場合です。ここで重要なのは、`constraint_exclusion` をいじっていた過去の遺産とは異なり、プランナがより洗練された形で「どのリレーションをスキャンすべきか」を決定している点です。

しかし、注意してください。パーティション数が数千を超えると、プランナが「どのパーティションをスキャンするか」を決定するコスト（Planning Time）が、クエリ実行時間よりも長くなるという逆転現象が起きます。数千のパーティションが必要な場合は、設計を見直すか、あるいはPostgreSQLのメタデータ管理の限界を疑うべきタイミングです。

—

2. パフォーマンストラブルシューティングの勘所

現場で「パーティション化したのに遅い」という相談を受けるとき、原因の9割は以下のいずれかに集約されます。

① インデックスの「迷走」

パーティションテーブルのインデックスは、親テーブルに定義しても子テーブルに自動伝播されますが、注意が必要です。子テーブルごとに統計情報が保持されるため、あるパーティションではインデックスが効くのに、別のパーティションでは全スキャンが選ばれる、といった「統計の不整合」が起きることがあります。
特に`VACUUM ANALYZE`のタイミングがパーティションごとにズレていると、プランナが「この子テーブルはデータが少ないはずだ」と誤認し、インデックスを使わないプランを立てるという悲劇が起こります。

② パーティション・キーの「罠」

ハッシュパーティショニングを採用する場合、キーの選択がすべてです。カーディナリティが低いカラムをキーにすると、特定のパーティションにデータが偏る「ホットスポット」が発生します。逆に、キーに対して更新（UPDATE）が発生する設計にしてしまうと、パーティション間での行の移動が発生し、非常に重いオーバーヘッドを招きます。パーティション・キーは「一度決めたら不変であるべき」という原則を忘れてはいけません。

③ 結合の最適化（Partition-wise Join）

大規模な結合を行う場合、デフォルトではパーティションを結合してから集計しますが、`enable_partitionwise_join = on` に設定することで、同じパーティション・キーを持つテーブル同士を、パーティション単位で結合させることができます。これを使いこなすと、メモリ消費を劇的に抑えられます。ただし、これはプランナの計算コストを跳ね上げるため、運用前に必ず `EXPLAIN ANALYZE` で計画作成時間を計測してください。

—

3. 「運用」こそが最大の難所

パーティション設計で最も過小評価されているのが、「データライフサイクル管理のコスト」です。

`DROP TABLE` でパーティションを捨てるのは非常に高速ですが、アプリケーション側で「どのパーティションをいつ捨てるか」というロジックを実装するのは骨が折れます。pg_partmanのような拡張機能を使うのが定石ですが、私はあえて言いたい。「自動化のロジックが複雑になりすぎるなら、設計が間違っている」と。

設計の理想形は、クエリが意識せずとも必要なデータだけにアクセスでき、メンテナンス処理が定型的なSQLだけで完結する状態です。複雑なトリガーや、アプリケーション側でのパーティション名指定などは、将来の自分に対する技術的負債でしかありません。

—

最後に：エンジニアとしての矜持

パーティショニングは、PostgreSQLという強力なエンジンの「ポテンシャルを解放する」ための外科手術のようなものです。正しく適用すれば、数TBのデータであっても、数msのレスポンスを実現できる。しかし、安易なパーティショニングは、単に管理コストを増やすだけの結果に終わります。

まずは、本当にインデックスのチューニングや、データの正規化、あるいはクエリの書き換えだけで解決できないのかを自問自答してください。その上で、物理レイアウトに踏み込む必要を感じたなら、この記事の知見があなたの武器になるはずです。

データベースは、正直です。我々が書いた設計の歪みは、必ず実行計画（EXPLAIN）に現れます。そのメッセージを読み解く楽しさを、ぜひ皆さんにも味わってほしいですね。