このような単純な計画にはそれほど役立ちませんが、http：//explain.depesz.comは本当に便利です。 http://explain.depesz.com/s/t4fiを参照してください。 [統計]タブと[オプション]プルダウンに注意してください。
この計画についての注意事項：
-
推定行数（183）は、実際の行数（25）にかなり匹敵します。数百倍も1もありません。行数の見積もり、つまり「1対1」の問題に関しては、桁違いに関心があります。 （「政府の仕事に十分近い」正確さは必要ありません-「軍の契約会計に十分近い」で十分です）。選択性の見積もりと統計は妥当なようです。
-
提供されている2列の部分インデックスを使用しています（
index scan using index_cars_onsale_on_brand_and_model_name）、したがって、部分インデックス条件に一致します。これは、Filter: has_auto_gearで確認できます。 。インデックス検索条件も表示されます。 -
テーブルの行数が、特に2列を超えるため、インデックスがかなり大きいことを意味することを考えると、クエリのパフォーマンスは妥当なように見えます。一致する行は分散するため、各行にも個別のページを読み取る必要がある可能性があります。
ここには何も問題はありません。ただし、このクエリはPostgreSQL9.2のインデックスのみのスキャンから大きな恩恵を受ける可能性があります。
ここにテーブルの肥大化がある可能性がありますが、2列のインデックスと行数を考えると、応答時間は完全に不合理ではありません。特に、それぞれに比較的少数のタプルを収める可能性が高い170（!!）列のテーブルの場合はそうです。ページ。ダウンタイムに余裕がある場合は、VACUUM FULLを試してください。 テーブルを再編成し、インデックスを再構築します。これにより、テーブルが再構築されている間、テーブルが排他的にロックされます。ダウンタイムに余裕がない場合は、pg_reorgおよび/またはCREATE INDEX CONCURRENTLYを参照してください。 およびALTER INDEX ... RENAME TO 。
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)が見つかるかもしれません バッファアクセスなどを表示できるため、より有益な場合があります。
このクエリを高速化する可能性のあるオプションの1つは（他のクエリの速度をいくらか遅くするリスクがありますが）、brandでテーブルを分割することです。 constraint_exclusionを有効にします 。パーティショニングを参照してください。