膨大な量の同じ値のインデックス作成/パフォーマンス戦略

Question

基本情報：これはOpenStreetMapデータのインデックス作成プロセスのコンテキストです。質問を簡略化するために、コア情報は、値「W」、「R」、「N」（VARCHAR(1)）の3つの主なタイプに分けられます。

テーブルは〜75Mの行のどこかにあり、 "W"の列はすべて〜42Mの行を構成します。既存の索引はこの質問には関係ありません。

---

質問自体：データの索引付けは手順で行います。この手順の中では、次のようなループがあります。

[...] SELECT * FROM table WHERE the_key = "W"; [...]

結果が再びループし、上記のクエリ自体もループしています。これには多くの時間がかかり、プロセスが大幅に遅くなります。インデックスが使用する可能性があるすべての値が同じ（「W」）であるため、インデックス番号the_keyは明らかに役に立たない。スクリプト自体は速度がOKで実行されており、SELECTには非常に時間がかかります。

ドI

• これを考慮してSELECTが迅速になり、インデックスの「特別」なものを作成する必要がありますか？もしそうなら、どちらですか？
• は、サーバパラメータの一部を調整する必要があります（すでに調整されており、配信された結果が良好であるようですが、必要に応じて投稿できます）。
• はスピードと共存してより多くのパワーを得るためにハードウェアを増やす必要があります（Tim Taylor grunt grunt）？

上記の点の代替手段（書き換えないし使用しない点を除く）はありますか？

Answer 1

work_memビットマップインデックススキャンを有効にするのに十分な高さに設定すると、このクエリでインデックスを使用できます。しかし、オプティマイザはまだそれを使用することを選択しません。全体的に、これについて最適化することはあまりありません。周囲のループコードが改善を必要としているようです。

Answer 2

まずあなたが言う：

表はどこか〜75Mの周り 行を持って、 "W" を持つすべての列が 〜42Mの行を構成しています。

次に、あなたがループ内で

SELECT * FROM table WHERE the_key = "W"; 

数回行うと、それを実行するために期待していると言いますか？これは不可能です。インデクシングはこのクエリをスピードアップすることはなく、42M行を返す必要があります。これは半分以上です。この索引作成手順を何度も繰り返すことを避けるためにこの索引作成手順を書き直すことを拒否した場合は、それはちょうどThe Daily WTFという価値があります。