1

私は単純な選択クエリを持っています:

SELECT * FROM entities WHERE entity_type_id = 1 ORDER BY entity_id

次に、最初の 100 件の結果を取得したいので、これを使用します。

SELECT * FROM entities WHERE entity_type_id = 1 ORDER BY entity_id LIMIT 100

問題は、2 番目のクエリが最初のクエリよりもはるかに遅く動作することです。最初のクエリを実行するのに 1 秒もかからず、2 番目のクエリを実行するのに 1 分以上かかります。

これらは、クエリの実行計画です。

制限なし:

Sort  (cost=26201.43..26231.42 rows=11994 width=72)
  Sort Key: entity_id
  ->  Index Scan using entity_type_id_idx on entities  (cost=0.00..24895.34 rows=11994 width=72)
        Index Cond: (entity_type_id = 1)

制限あり:

Limit  (cost=0.00..8134.39 rows=100 width=72)
  ->  Index Scan using xpkentities on entities  (cost=0.00..975638.85 rows=11994 width=72)
        Filter: (entity_type_id = 1)

なぜこれら 2 つのプランがそれほど異なるのか、なぜパフォーマンスが大幅に低下するのかがわかりません。2 番目のクエリをより高速に動作させるには、どのように調整すればよいですか?

PostgreSql 9.2 を使用しています。

4

1 に答える 1

1

条件に一致する 100 個の最小の entity_id が必要です。現在 - それらが 1..100 の数字である場合、これを処理する最善の方法は明らかに entity_id インデックスを使用することです - すべてが事前にソートされています。実際、必要な 100 が 1..200 の範囲内にある場合でも、意味があります。おそらく1..1000でしょう。

そのため、PostgreSQL は、テーブルの「開始」で多くの entity_type_id=1 値を見つけると考えています。タイプ別にフィルタリングして並べ替えると、8134 対 26231 のコストが見積もられます。あなたの場合、それは間違っています。

現在 - 明らかではない何らかの相関関係があるか (これは悪いことです - 現時点ではプランナーに伝えることができません)、最新または十分な統計情報がありません。

違いはありANALYZE entitiesますか？マニュアルの planner-stats ページを読むことで、プランナーが知っている値を確認できます。

于 2013-11-13T14:22:09.433 に答える