問題タブ [partial-index]

400 万件のレコードを含むテーブルがあり、特定の頻繁に使用されるユース ケースでは、400 万件のうち約 10,000 件の特定の salesforce userType が「標準」のレコードのみに関心があります。存在する可能性のある他のユーザー タイプは、'PowerPartner'、'CSPLitePortal'、'CustomerSuccess'、'PowerCustomerSuccess'、'CsnOnly' です。

したがって、このユースケースでは、ドキュメントに従って、部分インデックスを作成する方がよいと考えました。

したがって、この部分インデックスを作成して、usertype が「Standard」のレコードのクエリを高速化し、Web からのリクエストがタイムアウトになるのを防ぐことを計画しています。

ルックアップ クエリは次のようになります。

これが部分インデックスを作成する正しい方法であるかどうか確認していただけますか? それは大いに役立つでしょう。

DBルックアップをできる限り最適化しようとしています。私が理解していることから、私の目標は、唯一のステージが IXScan である winingPlan をターゲットにすることです。しかし、日付キーを含むフィールドがあり、「null」日付値でフィルタリングするときにドキュメントを直接検索できる複合インデックスを作成できないようです。

私のフィルタークエリは次のとおりです

このクエリに正確に対応する部分インデックスを作成してみました (たとえば、論理的に削除されたドキュメントを表示する必要がないことがわかっているため、インデックス メモリを節約するためです)。

(コードは Ruby ですが、Mongoid を使用すると問題なく MongoDB 言語に変換されることに注意してください)

soft_deleted_at私の勝利の計画は次のように見えるので、これはフィルターを除いてうまくいくようです

したがって、ここ"stage"=>"FETCH", "filter"=>{"soft_deleted_at"=>{"$eq"=>nil}},では、基本的に手動で日付フィールドを null 値でフィルタリングするこの追加の段階があります。これがすでに部分インデックスにあり、それ以上のフィルタリングを必要としないことを望んでいました...私は間違っていましたか?

この余分なフィルター段階を回避する方法はありますか?

プロジェクトで最大のテーブルの 1 つでパフォーマンス チューニングを行っています。インデックスについて読んでいるときに、PostgreSQL の部分インデックスに出会いました。これは、頻繁にアクセスされる行にのみインデックスを配置するという非常に良いアイデアに思えます。

ただし、部分インデックスがどのように更新されるかを理解することはできません。たとえば、次の列を持つテーブルがあります。

ENQUEUED非常に頻繁に状態にあるレコードを検索します。部分インデックスを追加する(task_uuid, task_status)と、一意のキーが構築され、パフォーマンスが向上します。しかし、私が知りたいのは、レコードが更新されたとき、レコードのRUNNINGステータスを更新したときに何が起こるかということです。(task_uuid, task_status)はまだ一意ですが、部分インデックスから削除されますか? レコードが条件を満たしていないためです。

私はレール移行スクリプトを持っています:

しかし、次のようにインデックスを生成します。

where 条件なし。レールのバージョン: ~> 4.2.11. postgreSQL 9.6 データベース