統計を理解する
クエリを実行するときは、データへのアクセス方法を決定するプランを作成する必要があります。 たとえば、SELECT クエリがすべての行を返す場合、インデックスを使う利点はなく、テーブル全体をスキャンする方が効率的です。 このシナリオのクエリ プランは簡単に作成できますが、ほとんどのクエリ プランは簡単に解決できません。
$10.00 から $20.00 のすべての注文を検索するクエリを実行しているシナリオを考えてください。 最初は、クエリがテーブル内のすべてのデータを返すのか、それとも小さなサブセットしか返さないのかわかりません。 このようにわからないため、データが見えるまでクエリ戦略を計画するのは困難です。 購入価格が $1.00 から $800.00 の注文がテーブルに含まれていることがわかっている場合、インデックスを使用してデータの小さなサブセットを検索できます。 ただし、適切なクエリ プランを生成するのに十分な情報がない可能性があります。 この例では、注文の購入価格の範囲は $1.00 から $800.00 ですが、注文の 95% は $10.00 から $20.00 の間であり、データのスキャンが実際に最も効果的なプランです。
前の例のようなシナリオの場合に PostgreSQL で最適なクエリ プランを使用できるためには、詳細な統計が必要です。
計画と実行の統計を監視するには、pg_stat_statements という名前の PostgreSQL 拡張機能があります。 Azure Database for PostgreSQL では pg_stat_statements は既定で有効になっており、pg_read_all_stats ロールのメンバーは複数の pg_stat ビューを使って統計をクエリできます。 次のクエリからは、pg_stat_activity ビューを使ってクエリ アクティビティが返されます。
SELECT * FROM pg_stat_activity;
pg_stat_statements をオフにする
クエリが独特なもので、同じクエリを定期的に繰り返さない場合、履歴クエリ データはあまり役に立ちません。 また、pg_stat ビューを使わないのでは、メリットは何もありません。 pg_stat_statements を維持するには最大で 50% のオーバーヘッドが発生するので、これらのシナリオでは pg_stat_statements の追跡をオフにしてもかまいません。
pg_stat_statements の追跡を無効にするには、次の手順のようにします。
Azure portal に移動し、利用している Azure Database for PostgreSQL サーバーを選びます。
[サーバー パラメーター] を選び、pg_stat_statements.track の設定に移動します。
追跡をオフにする場合、[NONE] を選択します。
より正確に追跡するには、[ALL] を選びます。
既定の設定は [TOP] です。
[保存] を選択します。
