本記事は「NTTデータがPostgreSQLを極限まで使い切ったその先に見たものとは？（前編）」の続きです。

実行計画をチェックするためにPostgreSQLを騙す。

　3つ目は実行計画のチェックです。PostgreSQLのSQL文はコストベースで実行されますので、統計情報を見て、テーブルをスキャンする方法、結合する方法などを選択するのですが、その選択が実行性能にとって重要です。そこで実行計画をチェックしました。


　ただし、本番環境でしかもサービス開始後のリアルな計画を開発環境で再現してチェックしなければ意味がありません。

　本来であれば本番環境と似たサンプルデータを用意して実行計画を作らせたかったのですが、なかなかデータを用意できなかったので、統計情報を操作してPostgreSQLをだます形でそれを実現しました。

　ただし統計情報はテーブルの中身によって更新されるため、一回騙す仕組みだけでなく騙し続ける仕組みも必要でした。そこで統計情報カスタマイズ機能を作りました。


　さらに、騙し続ける仕組みとして統計情報固定化機能も作りました。本来の統計情報を使わずに、つねに騙す方へ固定化できます。

　これで9割くらいはSQL文の問題が解決できるようになりました。しかしまだ最小限で最大限の効果が求められました。そこで、HINT句を使ってSQLチューニングをしました。


　そして5つ目の最後の手段としてSQL文の書き換えも行いました。

　この5つの関門を設定したことで、大量のSQL文の性能を守ることができました。


【次ページ】 >オープンソースの良さでトラブルを解決