日時フィールド「updated_at」を持つテーブルがあります。私のクエリの多くは、updated_at > 特定の日付を持つ行などの範囲クエリを使用して、このフィールドに対してクエリを実行します。
既に update_at にインデックスを追加しましたが、返される行数に制限があった場合でも、ほとんどのクエリは依然として非常に低速です。
日時フィールドに対してクエリを実行するクエリを最適化するには、他に何ができますか?
日時フィールド「updated_at」を持つテーブルがあります。私のクエリの多くは、updated_at > 特定の日付を持つ行などの範囲クエリを使用して、このフィールドに対してクエリを実行します。
既に update_at にインデックスを追加しましたが、返される行数に制限があった場合でも、ほとんどのクエリは依然として非常に低速です。
日時フィールドに対してクエリを実行するクエリを最適化するには、他に何ができますか?
通常、データベース オプティマイザーは、updated_at > somedate
.
ただし、多くの場合、datatime 列は「now」を超えないため、次のように条件を範囲に> somedate
変換することで、のセマンティックを保持できます。between
where updated_at between somedate and current_timestamp
述語があるbetween
と、オプティマイザーが索引の使用を選択する可能性が高くなります。
このアプローチによってクエリのパフォーマンスが向上したかどうかを投稿してください。
インデックスが使用されているがパフォーマンスがまだ悪いと仮定すると、私が考えることができる唯一の解決策は、そのインデックスでテーブルをクラスター化することです: http://www.postgresql.org/docs/9.1/static/sql-cluster.html
これにより、同じ update_at 値を持つ行が物理的に同じ場所に配置されるように移動され、特に大規模な範囲スキャンの場合に、インデックスを介してそのテーブルにアクセスするクエリのパフォーマンスが向上します。
ただし、ドキュメントの警告に注意してください。行が更新されると、クラスタリングが保持されないことに注意してください。
また:
テーブルがクラスター化されている場合、そのテーブルに対して ACCESS EXCLUSIVE ロックが取得されます。これにより、CLUSTER が終了するまで、他のデータベース操作 (読み取りと書き込みの両方) がテーブルに対して実行されなくなります。
これらの制限に基づいて、それはあなたの場合には実行可能な解決策ではないかもしれませんが、他の人には役立つかもしれません.