PostgreSQLのクエリが遅い、何が問題なのですか？

私は、Python Djangoを使用して私のpostgresql dbに測定データを保存しようとしています。これまでのところ、すべて私はdjangoでdockerコンテナを作成しました。もう1つはpostgresqlサーバーで作成しました。しかし、私は測定テーブルの2M行に近づいています。クエリは本当に遅くなり始めますが、なぜ、私は非常に強いクエリを実行していません。例えばPostgreSQLのクエリが遅い、何が問題なのですか？

このクエリ

SELECT ••• FROM "measurement" WHERE "measurement"."device_id" = 26 ORDER BY "measurement"."measure_timestamp" DESC LIMIT 20

私が照会され、デバイスに応じて、実行するために3〜5秒かかります。

私は何も気にしていないので、これはもっと速く動くと思います。 IDとmeasure_timestampにインデックスを持つ計測テーブル

id INTEGER 
measure_timestamp TIMESTAMP WITH TIMEZONE 
sensor_height INTEGER 
device_id INTEGER

。サーバーはあまりにもビジーではありません。512Mのメモリしかなくても、クエリ中に余裕があります。

shared_buffers = 256MBとwork_mem = 128MBのpostgresqlサーバを設定しました。合計データベースは100MBをわずかに下回っているため、簡単に適合するはずです。私はPgAdminでクエリを実行すると、ブロックI/Oが多く見えているので、ディスクから読み込む必要があると思われます（明らかに遅いです）。

問題を見つける方法を教えていただけないでしょうか？

EDIT：クエリでのexplain analyzeの出力を追加しました。 device_idにインデックスを追加しました。これは多くの助けになりましたが、クエリ時間がさらに短縮されることが期待されます。 https://pastebin.com/H30JSuWa

出典

2017-04-25 Marcovannoord

クエリに 'EXPLAIN（ANALYZE、BUFFERS）'を実行し、結果を質問に追加してください。それは推測だけに基づいていない答えを与えるのに役立ちます。 –

また、PK FKとインデックスを含む質問にテーブル定義を追加してください。また、カーディナリティなどのデータの記述もあります。 – joop

indexesはmeasure_timestampに、device_idにはありますか？クエリが常にそのフォームを使用する場合は、multi-column indexesも好きかもしれません。

出典

2017-04-25 09:43:56

まあ、私はやったと思ったが、device_idでは明らかにそうではなかったので、それを修正し、それは助けになったが、私はまだそこにはいない。 – Marcovannoord

あなたのお問い合わせはdescによる注文を行います。同じ方法でインデックスを作成してみてください。 https://www.postgresql.org/docs/current/static/indexes-ordering.html – Jayadevan

これは、答えに記載されている他のものと一緒に、このトリックを行いました。私はインデックスが「一方通行」であることを認識しておらず、インデックスを降順にインデックス付けすることができました。 Querytimeは5秒から22msになりました。ありがとう！ – Marcovannoord

テーブルの配布キーを確認してください。データにはまばらにデータが格納されている可能性があるため、パフォーマンスに影響します。 2Mレコードのデータを持つ場合、適切な配布キーを選択することは非常に重要です。詳細はこちらon why distribution key is important

出典

2017-04-25 09:48:34

PostgreSQLのクエリが遅い、何が問題なのですか？

答えて

関連する問題