6

delayd_jobは、次のようなクエリを定期的に実行します。

SELECT  "delayed_jobs".*
FROM "delayed_jobs"
WHERE ((run_at <= '2012-05-23 15:16:43.180810' AND (locked_at IS NULL OR locked_at < '2012-05-23 11:16:43.180841') OR locked_by = 'host:foo pid:1') AND failed_at IS NULL)
ORDER BY priority ASC, run_at ASC LIMIT 5

かなり大きなDBマシンのログでは、実行に1/4秒かかると報告されています。選択されているすべての列にいくつかのインデックスをスローすることもできますが、複数列のインデックスからパフォーマンスを向上させることができます。

このクエリに対して作成できる最適な複数列のインデックスは何ですか？これを計算できるツールはありますか？

アップデート

postgresバージョン：9.1.3

1つの既存のインデックス：priority、run_at（「delayed_jobs_priority」という名前）

からexplain analyze：

Limit  (cost=0.00..219.65 rows=5 width=1154) (actual time=0.727..0.727 rows=0 loops=1)
   ->  Index Scan using delayed_jobs_priority on delayed_jobs  (cost=0.00..351.43 rows=8 width=1154) (actual time=0.725..0.725 rows=0 loops=1)
         Filter: ((failed_at IS NULL) AND (((run_at <= '2012-05-23 18:11:03.980113'::timestamp without time zone) AND ((locked_at IS NULL) OR (locked_at < '2012-05-23 14:11:03.98014'::timestamp without time zone))) OR ((locked_by)::text = 'host:foo pid:1'::text)))
 Total runtime: 0.754 ms
(4 rows)
4

2 に答える 2

1

句があるためLIMIT、フィルタリングではなく順序付けインデックスが必要になる可能性があります(priority, run_at)。

条件を満たしているテーブル内のレコードの割合はWHERE?

于 2012-05-23T19:48:00.590 に答える
0

この場合、複数列のインデックスはあまり役に立たないと思います。複数の単一列インデックスを使用します。

于 2012-05-23T16:16:55.523 に答える