【PostgreSQL 11 新機能】パーティションキーを UPDATE した際の動作を検証してみた

こんにちは。サイオステクノロジー OSS サポート担当 Y です。

今回は PostgreSQL 11 (現時点ではまだ beta 版) にて強化された “パーティションキーを UPDATE した際の動作” を検証してみました。(※以下の内容は CentOS 7.5/PostgreSQL 10.5/PostgreSQL 11beta3 にて検証しています。)

■はじめに

昨年リリースされた PostgreSQL 10 の新機能である Declarative Partitioning では、一度特定の子テーブルに格納されたレコードの “パーティションキー” の値を、異なる子テーブルの条件に合致する値に更新しようとすると ERROR になり、子テーブル間でのデータ移動等は実施されない仕様になっていました。

しかし、PostgreSQL 11 では、パーティションキーを更新すると更新後の値に応じて子テーブル間でデータが移動される機能が実装される予定となっています。

今回は PostgreSQL 11beta3 を使って、このパーティションキーを更新した際の動作を試してみようと思います。

■検証 (PostgreSQL 10 の動作確認)

まずは PostgreSQL 10 の動作を確認してみます。(以下の例では LIST パーティションを使用しています)

上記テーブルに対して、まず list_key = 1 のレコードを INSERT します。すると、パーティショニングされたテーブル “hoge” にレコードが INSERT され、実際には子テーブル “hoge_child_1” にレコードが格納されていることが確認できます。

この状態で list_key の値を “2” に UPDATE しようとすると、以下の通り ERROR となってしまいます。これが PostgreSQL 10 の宣言的パーティショニングの仕様動作でした。

■検証 (PostgreSQL 11 の動作確認)

それでは、PostgreSQL 11beta3 で同じ処理を実行してみます。

まずは、前述した PostgreSQL 10 の検証と同じテーブルを作成します。

前述した PostgreSQL 10 の検証と同様に、list_key = 1 のレコードを INSERT し、子テーブル “hoge_child_1” にレコードが格納されていることを確認します。

この状態で list_key の値を “2” に UPDATE してみます。すると、PostgreSQL 10 の様に ERROR にはならずに、正常に UPDATE が実行されます。

上記 UPDATE 実行後に各テーブルの内容を参照してみると、list_key の値を “2” に UPDATE した “data = ‘hogehoge'” のレコードが、”hoge_child_1″ から “hoge_child_2” に移動していることが確認できます。

この様に、PostgreSQL 11 ではパーティションキーを UPDATE した際に適切な子テーブル (UPDATE 後の値が条件に合致する子テーブル) にレコードが移動されるようになっていることが確認できました。

■最後に

今回検証を実施した通り、PostgreSQL 11 ではパーティションキーを UPDATE した際に適切な子テーブルにレコードが移動されるため、パーティションキーを更新する可能性があるようなテーブルを作成することも可能になりました。PostgreSQL 11 では、その他にもパーティションに関連する複数の機能が強化されているため、PostgreSQL におけるパーティショニングがどんどん便利になっている様に感じます。

PostgreSQL 11 ではパーティション関連の機能を含め様々な機能が強化されているので、次回も PostgreSQL 11 の新機能の検証を実施してみようと思います。

>> 雑誌等の執筆依頼を受付しております。
   ご希望の方はお気軽にお問い合わせください!

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。

コメント投稿

メールアドレスは表示されません。


*