PostgreSQL 12に上げれるなら15まで基本的に上げれる。 自分もプロダクトで9.2から最近14まで上げましたが互換性、パフォーマンス共に問題なかった。
11,12から上げるところで大きな非互換はOIDの廃止だけど、基本的にそこに刺さる人はいないはず。
いたら returning 句を使う形に書き直しましょう。
または nextval() 先に値を取得する。
一般的なORMを使ってるような環境であれば一般的にそのへんは困らないはず。
公式ドキュメントは一通りみること
- https://lets.postgresql.jp/documents/technical/16
- https://lets.postgresql.jp/documents/technical/15
- https://lets.postgresql.jp/documents/technical/14
- https://lets.postgresql.jp/documents/technical/13
拡張、Extensionをインストールしている場合があるのでそこは要確認。
インストールしている拡張はSQL SELECT * FROM pg_extension; で確認できるので事前に確認すること。
Extensionをインストールしている場合はExtensionのバージョンアップを調べること。
公式があるので確認すること。 非推奨や削除された機能などが書いてある。
- https://www.postgresql.jp/document/15/html/release-15.html
- https://www.postgresql.jp/document/14/html/release-14.html
- https://www.postgresql.jp/document/13/html/release-13.html
バージョンアップ直後、統計情報とかが壊れててパフォーマンスが落ちることがある。 これはAWSのドキュメントにも記載がある。
ANALYZE 操作を実行して pg_statistic テーブルを更新します。これは、すべての PostgreSQL DB インスタンスのすべてのデータベースに対して行う必要があります。Optimizer の統計情報はメジャーバージョンのアップグレード中には転送されないため、パフォーマンスの問題を回避するためにすべての統計情報を再生成する必要があります。次のようにパラメータを指定せずにコマンドを実行して、現在のデータベース内のすべての標準テーブルの統計情報を生成します
とりあえずアップデートしたらANALYZEしましょう。
あと、文字コードやロケール周りも要注意。
PostgreSQLはinitdbの際にロケールを指定しない場合、OS側に設定されているロケールを使用します。この場合の多くは、ja_JP.UTF-8が選ばれるでしょう。これに伴いDBが壊れることはありませんし、エラーなどもありません。ただし、ソート関連に影響し、OSに依存してしまうことから、意図しない挙動をすることがあります。
例えばこういうのもあるし、あとから変えるのは大変なので要注意。
あとMySQLも同様だけど、パラメータがリセットされて設定が変わることがあるのは要注意。 デッドロックやチェックポイント周りのチューニングやタイムゾーンなどは漏れやすい。
特にRDSはデフォルトのタイムゾーンはUTCだし、ロケールはなのでen_US.UTF-8なので注意。
Managing spatial data with the PostGIS extension
AWSの手順書がちゃんとしているので参考にすること。#
PostgreSQL 10からNested Loop Joinを選びにくい
ちょいちょいある。