Amazon EC2 m1.largeのPostgres 9.1は時には本当に遅いクエリを持っています

Question

私は様々なpersonidと種類に対してこのクエリを見ましたが、10ミリ秒以下で、16分もかかることがわかりました。何が起こっている？

Column |  Type  |      Modifiers 
--------------+------------------+-------------------------------------------------------- 
id   | bigint   | not null default nextval('record_seq'::regclass) 
type   | integer   | not null 
personid  | integer   | 
reporttime | bigint   | not null 
totalreading | double precision | not null 
delta  | double precision | not null 

Indexes: 
    "record_pkey" PRIMARY KEY, btree (id) 
    "record_personid_idx" btree (personid) 
    "record_type_idx" btree (type) 
    "record_reporttime_idx" btree (reporttime) CLUSTER 

これは、時には本当に遅いクエリの説明分析です。

explain analyze SELECT ID, TYPE, REPORTTIME, TOTALREADING, DELTA, PERSONID FROM RECORD WHERE PERSONID=1103 AND TYPE=405 AND REPORTTIME <= 1332447354000 ORDER BY REPORTTIME DESC LIMIT 1; 

Limit (cost=0.00..327.93 rows=1 width=52) (actual time=239749.274..239749.274 rows=0 loops=1) 
    -> Index Scan Backward using record_reporttime_idx on record (cost=0.00..1196290.82 rows=3648 width=52) (actual time=239749.251..239749.251 rows=0 loops=1) 
     Index Cond: (reporttime <= 1332447354000::bigint) 
     Filter: ((personid = 1103) AND (type = 405)) 
Total runtime: 239749.409 ms 

約10-20種類あり、2つが最も頻繁に使用され、405はほとんど使用されません。

select count(*) from record; 
    count 
---------- 
30420232 

SELECT COUNT(*) FROM record WHERE PERSONID=1103 AND TYPE=405; 
    count 
------- 
    58 

Answer 1

プランナが何らかのターゲットの前に最後のレポート時間値を探しているので、それが意味をなされていると考えているからです。

これはたぶんほとんどの時間を行いますが、時折、（personid、type）の正しい組み合わせを見つけるために遠くに戻る必要があります。

一般的に（personid、type）を検索する場合は、両方または3つの列すべてで結合インデックスを試してください。 3つの列の順序と、他の索引を保持する必要があるかどうかは、照会の合計混合によって異なります。