0

列 C (btree index) に作成されたインデックスを持つテーブル T を作成しましたが、選択クエリを実行すると、このインデックスは使用されません。

元：

Explain select * from T where C='xxx'

これは、作成したインデックスを考慮せずに、すべてのセグメントを順番に検索します。

次のフラグを使用しました

enable_seqscan = off
enable_bitmapscan = off
enable_indexscan = on

何か不足していますか?親切に説明してください?

ありがとうガネーシュ.R

4

4 に答える 4

1

It's possible that the query optimizer, for whatever reason, thinks that it's better not to use the index. Also, you may need to do an ANALYZE on the table if the statistical metadata is out of date. See this article (or others like it) for more detailed information.

于 2011-07-27T14:25:51.250 に答える
1

理由explain analyzeを説明するのは非常に困難ですが、いくつかのポイントがあります。

  • GP は非常に高い random_page_cost を使用し、seq_page_cost は 1 です。random_page_cost のデフォルト値は 100 であり、オプティマイザーがインデックス スキャンを使用することを完全に思いとどまらせます
  • enable_seqscan = offseq スキャンを完全にオフにするわけではありません。seqスキャンは非常に
    不利です
  • テーブルが小さい場合 (100 ～ 10k レコード)、順番に読み取り、インデックスをまったく無視する方が速い場合があります。
于 2012-11-16T14:11:45.407 に答える
0

従来の RDBMS とは異なり、インデックスは Greenplum のデータにアクセスするための好ましい方法ではない場合があります。

Greenplum は、インデックス スキャンよりもテーブル スキャンを優先するように調整されており、それを変更するには多くの調整を行う必要があります。追加のパラメーターを設定して、GP オプティマイザーがset enable_nestloop on, cpu_index_tuple_cost およびその他を含むインデックスを選択できるようにすることができます。調整可能なパラメーターの完全なセットについては、GP 管理者ガイドの付録 D を確認してください。

また、どのようにデータを配布していますか? これは、オプティマイザーがクエリの処理を選択する方法に影響を与える可能性があります。

于 2011-11-04T19:39:56.687 に答える