博士

やあ、ロボ子。今日はデータベースのパフォーマンス問題について話すのじゃ。

ロボ子

博士、こんにちは。データベースのパフォーマンス問題ですか。具体的にはどのような問題でしょうか？

博士

今回は、大量の値を持つ`IN`句、いわゆるBig IN listsがパフォーマンスを悪化させるという問題じゃ。

ロボ子

`IN`句に大量の値があると、そんなにパフォーマンスが悪くなるんですね。どうしてでしょう？

博士

`IN`リストの値は定数として扱われて、統計情報が利用できないからのじゃ。それに、解析に時間がかかってメモリも消費するぞ。

ロボ子

なるほど。統計情報が使えないと、データベースが最適な実行計画を選べなくなるんですね。

博士

その通り！PostgreSQLがカーディナリティや行の選択性を誤って推定して、インデックススキャンではなくシーケンシャルスキャンを選んでしまう可能性が高まるのじゃ。

ロボ子

シーケンシャルスキャンは遅いですからね。具体的には、どのような状況でこの問題が発生しやすいのでしょうか？

博士

Active Recordで`pluck()`を使ってIDリストを作って、別のクエリに渡す場合とか、`includes`や`preload`のようなeager loadingメソッドを使う場合に発生しやすいのじゃ。

ロボ子

N+1問題を修正しようとして、逆にパフォーマンスが悪化してしまうこともあるんですね。

博士

そうならないための解決策もちゃんとあるぞ！クエリをJOIN操作に再構築したり、`IN`の代わりに`ANY`や`SOME`を使うのが有効じゃ。

ロボ子

`ANY`や`SOME`ですか。`IN`とどう違うんですか？

博士

`ANY`は配列を扱える柔軟性があるのじゃ。他にも、`VALUES`句を使ったり、一時テーブルを作ってインデックスを貼るのも効果的じゃぞ。

ロボ子

一時テーブルですか。それは少し手間がかかりそうですね。

博士

手間はかかるけど、効果は大きいぞ！あと、`ANY`演算子と配列を使うのも、`IN`リストよりパフォーマンスが向上する可能性があるのじゃ。プリペアドステートメントもサポートするしな。

ロボ子

なるほど。色々な解決策があるんですね。試すのが大変そうです。

博士

本番環境に近いデータでテストして、`EXPLAIN (ANALYZE, BUFFERS)`でクエリ実行計画を分析するのが大事じゃ。より少ないバッファアクセス、より低いコストを目指すのじゃ！

ロボ子

`EXPLAIN`は必須ですね。他に何か注意点はありますか？

博士

`pg_stat_statements`の`query`フィールドを`'%IN (%'`でフィルタリングして、問題のあるクエリを特定するのも良いぞ。

ロボ子

それ便利ですね！PostgreSQL自体も改善されているんですか？

博士

PostgreSQL 17では、スカラー式とインデックスの処理が効率化されるし、PostgreSQL 18では、`x IN (VALUES ...)`が自動的にScalarArrayOpExprに変換されるのじゃ。

ロボ子

着々と改善されているんですね。Rails側でも何か動きがあるんですか？

博士

Sean Linsleyが`IN`の代わりに`ANY`を使う修正に取り組んでいるらしいぞ。これでグルーピングの問題も解決するはずじゃ。

ロボ子

それは楽しみですね！データベースのパフォーマンス改善、奥が深いですね。

博士

そうじゃな。ところでロボ子、`IN`の反対は何じゃ？

ロボ子

`IN`の反対ですか？`NOT IN`でしょうか？

博士

ブー！正解は、`OUT`じゃ！…って、そんなコマンドないけどな！