Запрос Postgresql работает очень плохо

Question

У меня есть огромная проблема с производительностью запросов в моей базе данных postgresql. Версия PostgreSQL является: "PostgreSQL 8.4.3 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20070115 (prerelease) (SUSE Linux), 64-bit"

Я конфигурационный файл устанавливается следующим образом:

shared_buffers = 8GB 
effective_cache_size = 24GB 
work_mem = 419430kB 
maintenance_work_mem = 2GB 
checkpoint_segments = 128 
checkpoint_completion_target = 0.9 
wal_buffers = 16MB 
default_statistics_target = 500 
constraint_exclusion = on 

Запрос, который я должен выполнить это:

SELECT events.evt_id, events.evt_time, events.device_evt_time , to_ip_char(events.sip) , evt_agent.port , events.rv40 , events.evt , events.msg , events.sun , events.rv35 , events.dun , events.rv45 , events.fn , events.dp , events.trgt_trust_name , events.trgt_trust_domain , events.rv36 , events.rv43 , events.cv21 , events.cv40 , events.cv41 , events.cv42 , events.cv43 , events.cv44 , events.cv50 , events.cv51 , events.cv52 , events.cv53 , events.cv54 , events.cv55 , events.cv56 , events.cv35 , events.cv60 , events.cv61 , events.cv62 
FROM events, evt_agent 
WHERE 
    events.agent_id = evt_agent.agent_id AND (evt_agent.port::text = ANY (ARRAY['x'::character varying, 'y'::character varying, 'z'::character varying]::text[])) 
    AND events.evt::text <> 'Internal Message'::text 
    AND event_time > '2015-12-31 13:23:55.767+00'::timestamptz limit 10; 
ORDER BY events.evt_time; 

Таблица событий является секционированной таблицы, один раздел для каждого дня. Каждый раздел имеет два Сдерживает:

Name events_p_YYYYMMDDHHMISS_events_p_max_pk 
Columns evt_time, evt_id 
Name events_p_YYYYMMDDHHMISS_dc 
Definition evt_time > '2015-12-04 13:24:25.267973+00'::timestamp with time zone AND evt_time <= '2015-12-05 13:24:25.267973+00'::timestamp with time zone 

и семь индексов:

Name events_p_YYYYMMDDHHMISS_events_p_max_identity_ix1 
Columns evt_time, init_usr_identity_guid, rid02 
Operator classes timestamptz_ops, uuid_ops, int8_ops 

Name events_p_YYYYMMDDHHMISS_events_p_max_identity_ix2 
Columns evt_time, trgt_usr_identity_guid, rid02 
Operator classes timestamptz_ops, uuid_ops, int8_ops 

Name events_p_YYYYMMDDHHMISS_events_p_max_ix1  
Columns evt_time, sev, agent_id 
Operator classes timestamptz_ops, int4_ops, int8_ops 

Name events_p_YYYYMMDDHHMISS_events_p_max_ix2  
Columns evt_time, dip, sev 
Operator classes timestamptz_ops, int4_ops, int4_ops 

Name events_p_YYYYMMDDHHMISS_events_p_max_ix3  
Columns evt_time, res, sev 
Operator classes timestamptz_ops, text_ops, int4_ops 

Name events_p_YYYYMMDDHHMISS_events_p_max_ix4  
Columns evt_time, sip, sev 
Operator classes timestamptz_ops, int4_ops, int4_ops 

Name events_p_YYYYMMDDHHMISS_events_p_max_ix5  
Columns evt_time, txnmy_id, agent_id  
Operator classes timestamptz_ops, int8_ops, int8_ops 

Таблица evt_agent является словарем таблица с только около 20-30 строк.

сдерживает:

Name evt_agent_pk  
Columns agent_id 

индексирует:

Name evt_agent_ak1 
Columns agent, port, rn, pn, sn, st, device_ctgry, src_id, cust_id 
Operator classes text_ops, text_ops, text_ops, text_ops, text_ops, text_ops, text_ops, uuid_ops, int8_ops 

Name evt_agent_ix1 
Columns device_ctgry, agent_id 
Operator classes text_ops, int8_ops 

Когда я выполнить запрос я получил это объяснить план: http://explain.depesz.com/s/3xcu

Name evt_agent_ix2 
Columns st, agent_id  
Operator classes text_ops, int8_ops 

Name test_ev_ag_indx1  
Columns agent_id  
Operator classes int8_ops 

Я думал, что есть проблема со статистикой поэтому я «анализирую вакуум» все связанные таблицы, bu не улучшайте производительность запросов, объясните план.

Я попытался с «внутренним запросом» трюком, объяснить план здесь: http://explain.depesz.com/s/FAkH

Из того, что я могу понять это получил вид хуже.

У вас нет идеи, как получить лучший план выполнения для этого запроса? Чтобы получить любые результаты по запросу, потребуется около 42 минут.

Заранее благодарен!

Answer 1

Придется устранить хеш-соединение. Боковой присоединиться может быть просто ответ:

SELECT events.evt_id, events.evt_time, events.device_evt_time , to_ip_char(events.sip) , evt_agent.port , events.rv40 , events.evt , events.msg , events.sun , events.rv35 , events.dun , events.rv45 , events.fn , events.dp , events.trgt_trust_name , events.trgt_trust_domain , events.rv36 , events.rv43 , events.cv21 , events.cv40 , events.cv41 , events.cv42 , events.cv43 , events.cv44 , events.cv50 , events.cv51 , events.cv52 , events.cv53 , events.cv54 , events.cv55 , events.cv56 , events.cv35 , events.cv60 , events.cv61 , events.cv62 
FROM evt_agent, 
    LATERAL (SELECT * 
      FROM events AS e 
      WHERE 
      e.agent_id = evt_agent.agent_id 
      AND e.evt::text <> 'Internal Message'::text 
      AND e.event_time > '2015-12-31 13:23:55.767+00'::timestamptz 
      LIMIT 10000) AS events 
WHERE (evt_agent.port::text = ANY (ARRAY['x'::character varying, 'y'::character varying, 'z'::character varying]::text[]))   
ORDER BY events.evt_time 
LIMIT 10000; 

Пожалуйста, попробуйте его и без внутреннего предела и выкладывает объяснить планы оба.