PostgreSQL非パーティションキー列でプルーニングを実現する手法

PostgreSQLのパーティションテーブルにおいて、クエリパフォーマンスを最大化する上で最も強力な機能の一つがパーティションプルーニングだ。これは、クエリの述語（WHERE句）に基づいて、不要なパーティションをスキャン対象から除外する仕組みである。しかし、プルーニングが機能するのは基本的にパーティションキー列でフィルタリングした場合に限られる。この制約のため、適切なパーティションキーの選択は極めて難しい課題となる。

ところが、データに特定のパターンが存在する場合、巧妙なテクニックを組み合わせることで、非パーティションキー列でのフィルタリングにおいてもプルーニングを実現できることが、Lobstersに掲載されたHaki Benita氏の記事で詳しく解説されている。本稿では、同記事の内容を基に、実践的なアプローチを紹介する。

パーティション設計の基本と課題

典型的な例として、イベントログを格納するテーブルを考えよう。多くのWebサービスでは、ユーザーセッション単位でイベントを記録し、タイムスタンプでパーティション分割する。例えば、年に1つのパーティションを作成し、2025年のデータをevent_y2025、2026年のデータをevent_y2026に格納する。

この設計では、特定の日付範囲のクエリは該当するパーティションのみをスキャンするため、高速に処理できる。しかし、session_idなどの非パーティションキー列でフィルタリングするクエリは、全パーティションをスキャンすることになり、パーティションの利点を活かせない。ユーザー単位の分析や特定セッションの調査が必要な場合、これは深刻なパフォーマンス問題を引き起こす。

ローカルインデックスとグローバルインデックス

パーティションテーブルにおけるインデックス戦略は、プルーニングの補完手段として重要だ。ローカルインデックスは各パーティションに独立して作成されるため、パーティションキーによるプルーニングが行われた後、各パーティション内での高速な検索を提供する。一方、グローバルインデックスは全パーティションにまたがるインデックスであり、非パーティションキー列での検索を高速化できるが、メンテナンスコストが高い。

従来の常識では、非パーティションキー列のクエリを高速化するにはグローバルインデックスに頼るしかない。しかし、大規模テーブルではグローバルインデックスの構築と更新がボトルネックとなる。ここで、Benita氏が提示するテクニックが有効になる。

Constraint Exclusionパラメータの活用

PostgreSQLにはconstraint_exclusionという設定パラメータが存在する。このパラメータは、テーブルに定義されたCHECK制約を利用して、不要なテーブルをスキャン対象から除外する機能を提供する。パーティションプルーニングはパーティションキーに基づくが、constraint_exclusionは任意のCHECK制約を評価する。

デフォルトではconstraint_exclusionはpartition（パーティションでのみ有効）に設定されている。これをonに変更すると、パーティションテーブルだけでなく、通常のテーブルでもCHECK制約による除外が有効になる。ただし、全てのテーブルで制約をチェックするため、オーバーヘッドが発生する点に注意が必要だ。

Benita氏のアプローチでは、このconstraint_exclusionを特定の条件下で利用し、非パーティションキー列によるプルーニングを実現する。具体的には、データに「アウトライア（外れ値）」や「ギャップ・アンド・アイランド」パターンが存在する場合に、それらを利用して効果的な制約を定義する。

アウトライアを利用したプルーニング

あるセッションIDが特定の時間範囲にのみ出現する場合、そのセッションIDと時間範囲の対応関係をCHECK制約としてパーティションに追加できる。例えば、セッションID=1が2025年12月28日〜29日のみに存在するなら、session_id = 1 AND timestamp BETWEEN '2025-12-28' AND '2025-12-29'という制約を該当パーティションに付与する。

通常、このような制約は手動で管理するのは現実的ではない。しかし、データの生成パターンが規則的な場合（例えば、セッションIDが連番で、開始時刻が一定間隔で増加する場合）、セッションIDの範囲と時間範囲の間に相関関係が生まれる。この相関を利用して、各パーティションに「このパーティションに含まれるsession_idの範囲」をCHECK制約として追加する。

具体的には、パーティション作成時に、そのパーティションがカバーする時間範囲に対応するセッションIDの最小値と最大値を計算し、CHECK (session_id BETWEEN min AND max)を追加する。これにより、WHERE session_id = 12345のようなクエリを実行する際、PostgreSQLのプランナは各パーティションのCHECK制約を評価し、範囲外のパーティションを除外できる。これがプルーニングとして機能する。

ギャップ・アンド・アイランドパターン

時間範囲とセッションIDの対応が完全な連続ではない場合（ギャップが存在する場合）でも、同様の手法は応用可能だ。データが「アイランド」（連続した塊）として存在する場合、各アイランドを1つのパーティションに対応させ、そのアイランド内のセッションID範囲をCHECK制約として定義する。これにより、ギャップが存在しても、該当パーティションのみがスキャンされる。

ただし、この手法はデータの生成パターンが予測可能であることが前提となる。例えば、イベントログがタイムスタンプ順に挿入され、セッションIDが自動インクリメントである場合、時間とセッションIDの間には強い相関が生まれる。逆に、ランダムに割り当てられるセッションIDや、時間と無関係に生成されるIDでは、この手法は機能しない。

アウトライアの処理

非パーティションキー列でのプルーニングを実現する上で、アウトライア（外れ値）の扱いが重要になる。例えば、一部のセッションが非常に長期間にわたる場合、1つのセッションが複数のパーティションにまたがることがある。このようなデータは、CHECK制約によるプルーニングを破綻させる可能性がある。

Benita氏の記事では、アウトライアを専用のパーティションに隔離する手法が提案されている。例えば、長時間セッションを特別なパーティションに移動し、そのパーティションにはsession_idの範囲制約を設けない。これにより、通常のクエリでは大部分のパーティションがプルーニングされる一方、アウトライアを含むパーティションは常にスキャンされるが、その数は限定される。

プランナとの対話

PostgreSQLのクエリプランナは、統計情報と制約情報を基に最適な実行計画を選択する。非パーティションキー列でのプルーニングを有効にするには、プランナが各パーティションの制約を正確に評価できる必要がある。そのためには、constraint_exclusionパラメータの適切な設定に加え、統計情報の更新（ANALYZE）が欠かせない。

また、プランナの動作を確認するにはEXPLAINコマンドが有効だ。実行計画の中で「Append」ノードの子ノードが減少していれば、プルーニングが成功している証拠となる。一方、全てのパーティションがリストされている場合、プルーニングが機能していないことを示す。

実運用上の注意点

これらのテクニックを実運用で採用する際には、いくつかの注意点がある。

第一に、CHECK制約の追加はデータの整合性を保つために慎重に行う必要がある。誤った制約を追加すると、正しいデータが挿入できなくなる。制約は常にデータの実際の分布と一致している必要があり、新たなデータの挿入パターンが変化した場合、制約を更新するメンテナンスプロセスが必要になる。

第二に、constraint_exclusionをonに設定すると、全てのテーブルでCHECK制約の評価が行われるため、CPUオーバーヘッドが増加する。大規模なデータベースでは、このオーバーヘッドが無視できない場合がある。通常はpartitionのままにし、特定のクエリセッションでのみconstraint_exclusionを有効にする方が現実的かもしれない。

第三に、プルーニングが機能するかどうかはクエリの述語に依存する。等価条件（=`）や範囲条件（BETWEEN, <, >）であれば機能するが、INリストやOR条件では制約評価が複雑になり、期待通りに動作しない可能性がある。

従来手法との比較

従来、非パーティションキー列での高速なクエリを実現する手段としては、グローバルインデックスやマテリアライズドビューが主に使用されてきた。グローバルインデックスは手軽だが、パーティションの追加・削除時におけるインデックスメンテナンスが課題となる。マテリアライズドビューは集計結果を保存するため、リアルタイム性が要求されない分析クエリに適している。

Benita氏の手法は、これらと比較して以下の長所を持つ。まず、パーティション管理のオーバーヘッドを増やさずに、非パーティションキー列でもプルーニングの恩恵を受けられる。次に、スキーマ設計の工夫のみで実現できるため、特別なインフラやライセンスは不要である。ただし、データパターンに強く依存するため、汎用的な解決策ではない。使用する前に、自身のデータが前提条件を満たしているかを検証する必要がある。

編集部の見解

短期的には、この手法はイベントログや時系列データを扱うシステムにおいて、セッション単位の分析クエリのパフォーマンスを改善する選択肢となる。特に、パーティションキーを変更できない既存システムでのチューニング手法として価値がある。データの生成パターンが規則的な場合、グローバルインデックスを回避できるため、書き込み負荷の高いシステムでも適用可能だ。 長期的に見ると、PostgreSQL自体のパーティションプルーニング機能の進化が期待される。現状ではパーティションキー以外の列でのプルーニングは標準機能ではないが、将来的にプランナが統計情報から自動的に制約を推論できるようになる可能性がある。また、このようなコミュニティレベルの工夫が、PostgreSQLのコア開発におけるフィードバックとして機能する点も見逃せない。データベース設計者は、提供される機能の制約を理解しつつ、創造的な回避策を模索する姿勢が問われる。 編集部としては、この手法を採用する前に、データの分布とクエリパターンを詳細に分析する必要があると考える。

参考

• Lobsters — 2026-07-09T10:43:36.000Z公開