Запросы к базе стали выполняться значительно медленней.
Стал смотреть план запроса, обратил внимание на большое количество циклов.
Подскажите, в чем может быть причина, большого количества loops в плане запроса?
Nested Loop Left Join (cost=2.80..17.66 rows=1 width=245) (actual time=373.387..113483.812 rows=1 loops=1)
-> Nested Loop Left Join (cost=2.52..15.15 rows=1 width=184) (actual time=373.379..113483.804 rows=1 loops=1)
Join Filter: (t1._idrref = t5._fld21037rref)
-> Nested Loop Left Join (cost=1.95..10.08 rows=1 width=135) (actual time=373.369..113483.794 rows=1 loops=1)
Join Filter: (t1._fld5345rref = t6._idrref)
Rows Removed by Join Filter: 706
-> Index Scan using _reference279hpk on _reference279 t1 (cost=0.29..1.89 rows=1 width=40) (actual time=0.017..0.023 rows=1 loops=1)
Index Cond: ((_fld1077 = 137::numeric) AND (_idrref = '\\x80c3f9aa551a7ef811e7be6e3605cc45'::bytea))
-> Nested Loop Left Join (cost=1.67..8.18 rows=1 width=135) (actual time=188.655..113483.474 rows=707 loops=1)
Join Filter: ((t6._fld2543_type = CASE WHEN (t7._idrref IS NOT NULL) THEN '\\x08'::bytea ELSE NULL::bytea END) AND (t6._fld2543_rtref = CASE WHEN (t7._idrref IS NOT NULL) THEN '\\x0000014d'::bytea ELSE NULL::bytea END) AND (t6._fld2543_rrref = t7._idrref))
Rows Removed by Join Filter: 357238
-> Index Scan using _reference125hpk on _reference125 t6 (cost=0.42..2.03 rows=1 width=53) (actual time=0.031..1.150 rows=707 loops=1)
Index Cond: (_fld1077 = 137::numeric)
-> Nested Loop Left Join (cost=1.25..6.14 rows=1 width=135) (actual time=0.316..160.267 rows=506 loops=707)
Join Filter: (t7._idrref = t11._fld24519rref)
Rows Removed by Join Filter: 505
-> Index Scan using _reference333hpk on _reference333 t7 (cost=0.42..2.02 rows=1 width=70) (actual time=0.009..0.303 rows=506 loops=707)
Index Cond: (_fld1077 = 137::numeric)
-> Nested Loop (cost=0.83..4.10 rows=1 width=65) (actual time=0.101..0.315 rows=1 loops=357742)
Join Filter: ((t10._fld24519rref = t11._fld24519rref) AND ((max(t10._period)) = t11._period))
Rows Removed by Join Filter: 503
-> GroupAggregate (cost=0.41..2.05 rows=1 width=27) (actual time=0.090..0.090 rows=1 loops=357742)
Group Key: t10._fld24519rref
-> Index Only Scan using _inforg24518_byperiod on _inforg24518 t10 (cost=0.41..2.03 rows=1 width=27) (actual time=0.021..0.090 rows=1 loops=357742)
Index Cond: ((_fld1077 = 137::numeric) AND (_period <= '2017-11-07 14:02:00'::timestamp without time zone) AND (_fld24519rref = '\\x80c3f9aa551a7ef811e7be6e3605cc38'::bytea))
Heap Fetches: 357742
-> Index Scan using _inforg24518_byperiod on _inforg24518 t11 (cost=0.41..2.03 rows=1 width=73) (actual time=0.010..0.140 rows=504 loops=357742)
Index Cond: (_fld1077 = 137::numeric)
-> Nested Loop (cost=0.57..5.05 rows=1 width=69) (actual time=0.009..0.009 rows=0 loops=1)
Join Filter: ((max(t4._period)) = t5._period)
-> GroupAggregate (cost=0.29..2.52 rows=1 width=28) (actual time=0.008..0.008 rows=0 loops=1)
Group Key: t4._fld21037rref
-> Index Only Scan using _inforg21036_byperiod on _inforg21036 t4 (cost=0.29..2.51 rows=1 width=28) (actual time=0.008..0.008 rows=0 loops=1)
Index Cond: ((_fld1077 = 137::numeric) AND (_period <= '2017-11-07 14:02:00'::timestamp without time zone) AND (_fld21037rref = '\\x80c3f9aa551a7ef811e7be6e3605cc45'::bytea))
Heap Fetches: 0
-> Index Scan using _inforg21036_byperiod on _inforg21036 t5 (cost=0.29..2.50 rows=1 width=69) (never executed)
Index Cond: ((_fld1077 = 137::numeric) AND (_fld21037rref = '\\x80c3f9aa551a7ef811e7be6e3605cc45'::bytea))
-> Index Scan using _reference82hpk on _reference82 t12 (cost=0.28..2.50 rows=1 width=80) (actual time=0.000..0.000 rows=0 loops=1)
Index Cond: ((_fld1077 = 137::numeric) AND (t5._fld21040rref = _idrref))
Planning time: 5.606 ms
Execution time: 113484.007 ms
Если структура БД не
Если структура БД не менялась, то попробуйте просто прогнать ручками VACUUM FULL и VACUUM ANALYZE на таблицах, которые участвуют в запросе.
Скорей всего Вы правы, т.к.
Спс. скорей всего Вы правы, т.к. после переноса в тестовую базу, подобных ошибок не наблюдается и запросы выполняются быстро.
А есть какие-то способы понять что нужно выполнить VACUUM FULL и VACUUM ANALYZE (Может можно запросом посм. что давно не выполнялся VACUUM)?
Что именно нужно посм. в тестовой и боевой базе, что бы точно убедиться что ошибка из-за не выполнения VACUUM FULL и VACUUM ANALYZE?
Запускаю VACUUM _inforg24518
Запускаю VACUUM _inforg24518 на тестовом, отрабатывает за милисек., а на боевом завис процесс, подскажите, с чем это может быть связано?
Выполнил VACUUM на прямую, не
Выполнил VACUUM на прямую, не через PGAdmin, все получилось запросы залетали. Спасибо!