部分インデックスは良い考えです 明らかに必要のないテーブルの行の半分を除外します。よりシンプル:
CREATE INDEX name_idx ON table (text_col)
WHERE text_col IS NOT NULL;
必ずANALYZE table
を実行してください インデックスを作成した後。 (Autovacuumは、手動で実行しない場合、しばらくすると自動的に実行されますが、作成直後にテストすると、テストは失敗します。)
次に、特定の部分インデックスを使用できることをクエリプランナーに納得させるために、WHERE
を繰り返します。 クエリの条件-完全に冗長に見える場合でも:
SELECT col1,col2, .. colN
FROM table
WHERE text_col = 'my_value'
AND text_col IS NOT NULL; -- repeat condition
Voilá。
ドキュメントごと:
ただし、述語は、インデックスの恩恵を受けると想定されるクエリで使用される条件と一致する必要があることに注意してください。正確に言うと、システムが
WHERE
を認識できる場合にのみ、部分インデックスをクエリで使用できます。 クエリの条件は、数学的にインデックスの述語を意味します。 PostgreSQLには、さまざまな形式で記述された数学的に同等の式を認識できる高度な定理証明者がありません。 (このような一般定理証明は作成が非常に難しいだけでなく、実際に使用するには遅すぎる可能性があります。)システムは単純な不等式の意味を認識できます。たとえば、「x<1」は「x<2」を意味します。それ以外の場合は述語です。条件は、クエリのWHERE
の一部と完全に一致する必要があります 条件またはインデックスは使用可能として認識されません。マッチングは、実行時ではなく、クエリプランニング時に行われます。その結果、パラメーター化されたクエリ句は部分インデックスでは機能しません。
パラメータ化されたクエリの場合:ここでも、部分インデックスの(冗長な)述語を追加の定数WHERE
として追加します。 状態、そしてそれはうまく機能します。
Postgres 9.6の重要な更新 インデックスのみのスキャンの可能性が大幅に向上します (これにより、クエリがより安価になり、クエリプランナーはそのようなクエリプランをより簡単に選択できるようになります)。関連:
- PostgreSQLはcount(*)中にインデックスを使用しません