Postgres 9.1 на Amazon EC2 m1.large иногда имеет очень медленный запрос - PullRequest
Новая
       7

Postgres 9.1 на Amazon EC2 m1.large иногда имеет очень медленный запрос

0 голосов
/ 23 марта 2012

Я видел, что этот запрос для разных персон и разных типов занимал менее 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

1 Ответ

1 голос
/ 23 марта 2012

Поскольку вы ищете последнее значение отчета, прежде чем какая-то цель, планировщик считает, что поиск в обратном направлении имеет смысл.

Вероятно, это происходит некоторое время / большую часть времени, но иногда вам приходится идти далеко назад, чтобы найти правильную комбинацию (personid, type).

Если вы обычно выполняете поиск (personid, type), попробуйте комбинированный индекс по обоим или, возможно, даже по всем трем столбцам. Порядок трех столбцов и необходимость сохранения других индексов будут зависеть от общего количества запросов.

...