2015-03-11 3 views
0

У меня простой запрос по одной таблице, и проблема в медленной производительности. Это определение таблицы:Медленный запрос в postgresql

-- Table: variable_logs 

CREATE TABLE variable_logs 
(
    id serial NOT NULL, 
    variable_id integer, 
    created_at timestamp without time zone, 
    updated_at timestamp without time zone, 
    "timestamp" timestamp without time zone, 
    value character varying(255)[] DEFAULT '{}'::character varying[], 
    CONSTRAINT variable_logs_pkey PRIMARY KEY (id) 
) 
WITH (
    OIDS=FALSE 
); 
ALTER TABLE variable_logs 
    OWNER TO postgres; 
ALTER TABLE variable_logs ALTER COLUMN created_at SET STATISTICS 1000; 


-- Index: idx_time_limits_inversed 

-- DROP INDEX idx_time_limits_inversed; 

CREATE INDEX idx_time_limits_inversed 
    ON variable_logs 
    USING btree 
    (variable_id, created_at DESC); 

В основном это таблица, в которой я сохранить данные каждый раз, когда X (пример: 10 секунд), и он быстро растет. Столбец «значение» содержит только 1 элемент в массиве для каждой строки.

версия Postgresql является: "PostgreSQL 9.1.14 на x86_64-неизвестно-Linux-гну, составленный НКУ (Ubuntu/Linaro 4.8.1-10ubuntu8) 4.8.1, 64-бит"

Теперь таблица имеет около 653941 строки, и запрос по таблице (без какого-либо соединения) выполняется медленно.

SELECT variable_logs.created_at, variable_logs.variable_id, variable_logs.value 
FROM variable_logs 
WHERE variable_logs.variable_id = 2 
AND (variable_logs.created_at BETWEEN '2015-01-01 00:00:00.000000' 
            AND '2015-03-09 23:59:00.000000') 
ORDER BY created_at asc 

Total query runtime: 13979 ms. 
184369 rows retrieved. 

Если я выполнить тот же запрос без порядка и фильтра над датами:

SELECT variable_logs.created_at, variable_logs.variable_id, variable_logs.value 
FROM variable_logs 
WHERE variable_logs.variable_id = 2 

Total query runtime: 14035 ms. 
184369 rows retrieved. 

Запрос всегда идут медленно, и я стараюсь делать VACUUM и ANALYZE с таким же медленным результатом.

EXPLAIN (ANALYZE on, VERBOSE off, COSTS on, BUFFERS on) 
SELECT variable_logs.created_at, variable_logs.variable_id, variable_logs.value 
FROM variable_logs 
WHERE variable_logs.variable_id = 2 
    AND (variable_logs.created_at BETWEEN '2015-01-01 00:00:00.000000' 
            AND '2015-03-09 23:59:00.000000') 
ORDER BY created_at asc; 

"Sort (cost=32374.66..32835.00 rows=184137 width=53) (actual time=150.983..160.467 rows=184369 loops=1)" 
" Sort Key: created_at" 
" Sort Method: quicksort Memory: 27833kB" 
" Buffers: shared hit=8570" 
" -> Bitmap Heap Scan on variable_logs (cost=5188.10..16271.50 rows=184137 width=53) (actual time=33.239..70.201 rows=184369 loops=1)" 
"  Recheck Cond: ((variable_id = 2) AND (created_at >= '2015-01-01 00:00:00'::timestamp without time zone) AND (created_at <= '2015-03-09 23:59:00'::timestamp without time zone))" 
"  Buffers: shared hit=8570" 
"  -> Bitmap Index Scan on idx_time_limits_inversed (cost=0.00..5142.06 rows=184137 width=0) (actual time=31.935..31.935 rows=184369 loops=1)" 
"    Index Cond: ((variable_id = 2) AND (created_at >= '2015-01-01 00:00:00'::timestamp without time zone) AND (created_at <= '2015-03-09 23:59:00'::timestamp without time zone))" 
"    Buffers: shared hit=709" 
"Total runtime: 170.038 ms" 

Я попытался изменить конфигурацию postgres.conf после руководства «Вещи, чтобы попробовать, прежде чем сообщение» на https://wiki.postgresql.org/wiki/Slow_Query_Questions без успеха; (

+0

у ели В первую очередь это конечный «порядок по дате_created» (-> шаг сортировки), который делает его «медленным». – wildplasser

+1

Пожалуйста, включите соответствующую информацию в вопрос здесь. Не связывайтесь с внешними ресурсами. –

+0

@wildplasser, если я удалю порядок сортировки, это то же самое (.. Если я выполняю тот же запрос без ордеров и фильтров по датам: SELECT variable_logs.created_at, variable_logs.variable_id, variable_logs.value FROM variable_logs WHERE variable_logs. variable_id = 2 Общая продолжительность выполнения запроса: 14035 мс. 184369 полученных строк – Christian

ответ

0

Вы с извлечением 23% строк в таблице. Я бы не ожидал, что использование индекса будет полезно, если оно не охватит все столбцы, необходимые для запроса, и предоставит требуемый порядок сортировки.

Дайте ему перейти без индекса, а затем с индексом на (variable_id, created_at, value)

+0

тот же запрос без индекса: Total query runtime: 14575 ms. 184369 найденные строки. – Christian

+0

с индексом on (variable_id, created_at, value) тот же самый запрос принимает Total runtime времени выполнения: 14420 ms. ( – Christian

+0

). Вы также можете показать результаты анализа для тех, кто тоже. –

Смежные вопросы