Обсуждение: Postgres 9.6. Большое planning time в простом запросе
Коллеги,
после обновления до 9.6 стали медленно исполнятся некоторые запросы.
Попытался проанализировать и вижу, что в некоторых случаях на достаточно простых запросах долго строится execution plan.
Для примера вот запрос:
Попытался проанализировать и вижу, что в некоторых случаях на достаточно простых запросах долго строится execution plan.
Для примера вот запрос:
SELECT
T1.*
FROM _Reference54 T1
LEFT OUTER JOIN _InfoRg4210 T2
ON T1._Fld9680RRef = T2._Fld4213RRef
WHERE ((T1._Fld5384 = 0)) AND ((T1._IDRRef = '\202\260\360yYn\310\234\021\346\376U\244\354w\227'::bytea))
EXPLAIN ANALYSE показывает "Planning time: 1425.054 ms" при том, что "Execution time: 126.907 ms".
В чем проблема? Как можно ускорить планирование?
Nested Loop Left Join (cost=0.98..13291.41 rows=5619 width=237) (actual time=40.649..126.838 rows=1 loops=1)
-> Index Scan using _reference54hpk on _reference54 t1 (cost=0.43..2.65 rows=1 width=237) (actual time=0.066..0.068 rows=1 loops=1)
Index Cond: ((_fld5384 = '0'::numeric) AND (_idrref = '\202\260\360yYn\310\234\021\346\376U\244\354w\227'::bytea))
-> Index Only Scan using _inforg4210_bydims_rrrrr on _inforg4210 t2 (cost=0.55..13288.75 rows=1 width=19) (actual time=40.578..126.764 rows=1 loops=1)
Index Cond: (_fld4213rref = t1._fld9680rref)
Heap Fetches: 0"
Planning time: 1425.054 ms
Execution time: 126.907 ms
----
С уважением,Людмирский Николай
Первое, что в голову приходит - вы статистику обновляли после апгрейда?
2018-03-12 17:11 GMT+01:00 Nik Ludmirsky <ludmirsky@gmail.com>:
Коллеги,после обновления до 9.6 стали медленно исполнятся некоторые запросы.
Попытался проанализировать и вижу, что в некоторых случаях на достаточно простых запросах долго строится execution plan.
Для примера вот запрос:SELECTT1.*FROM _Reference54 T1LEFT OUTER JOIN _InfoRg4210 T2ON T1._Fld9680RRef = T2._Fld4213RRefWHERE ((T1._Fld5384 = 0)) AND ((T1._IDRRef = '\202\260\360yYn\310\234\021\346\376U\244\354w\227'::bytea) ) EXPLAIN ANALYSE показывает "Planning time: 1425.054 ms" при том, что "Execution time: 126.907 ms".В чем проблема? Как можно ускорить планирование?Nested Loop Left Join (cost=0.98..13291.41 rows=5619 width=237) (actual time=40.649..126.838 rows=1 loops=1)-> Index Scan using _reference54hpk on _reference54 t1 (cost=0.43..2.65 rows=1 width=237) (actual time=0.066..0.068 rows=1 loops=1)Index Cond: ((_fld5384 = '0'::numeric) AND (_idrref = '\202\260\360yYn\310\234\021\346\376U\244\354w\227'::bytea) ) -> Index Only Scan using _inforg4210_bydims_rrrrr on _inforg4210 t2 (cost=0.55..13288.75 rows=1 width=19) (actual time=40.578..126.764 rows=1 loops=1)Index Cond: (_fld4213rref = t1._fld9680rref)Heap Fetches: 0"Planning time: 1425.054 msExecution time: 126.907 ms----С уважением,
Людмирский Николай
Regards, Andrei Lizenko
Конечно, но речь не о качестве плана, а о скорости построения этого плана
12 мар. 2018 г. 19:16 пользователь "Andrey Lizenko" <lizenko79@gmail.com> написал:
Первое, что в голову приходит - вы статистику обновляли после апгрейда?2018-03-12 17:11 GMT+01:00 Nik Ludmirsky <ludmirsky@gmail.com>:Коллеги,после обновления до 9.6 стали медленно исполнятся некоторые запросы.
Попытался проанализировать и вижу, что в некоторых случаях на достаточно простых запросах долго строится execution plan.
Для примера вот запрос:SELECTT1.*FROM _Reference54 T1LEFT OUTER JOIN _InfoRg4210 T2ON T1._Fld9680RRef = T2._Fld4213RRefWHERE ((T1._Fld5384 = 0)) AND ((T1._IDRRef = '\202\260\360yYn\310\234\021\346\376U\244\354w\227'::bytea)) EXPLAIN ANALYSE показывает "Planning time: 1425.054 ms" при том, что "Execution time: 126.907 ms".В чем проблема? Как можно ускорить планирование?Nested Loop Left Join (cost=0.98..13291.41 rows=5619 width=237) (actual time=40.649..126.838 rows=1 loops=1)-> Index Scan using _reference54hpk on _reference54 t1 (cost=0.43..2.65 rows=1 width=237) (actual time=0.066..0.068 rows=1 loops=1)Index Cond: ((_fld5384 = '0'::numeric) AND (_idrref = '\202\260\360yYn\310\234\021\346\376U\244\354w\227'::bytea)) -> Index Only Scan using _inforg4210_bydims_rrrrr on _inforg4210 t2 (cost=0.55..13288.75 rows=1 width=19) (actual time=40.578..126.764 rows=1 loops=1)Index Cond: (_fld4213rref = t1._fld9680rref)Heap Fetches: 0"Planning time: 1425.054 msExecution time: 126.907 ms----С уважением,
Людмирский Николай--Regards, Andrei Lizenko
Не ваш случай?
The problem is that you have too many partitions.
2018-03-12 18:38 GMT+01:00 Nik Ludmirsky <ludmirsky@gmail.com>:
Конечно, но речь не о качестве плана, а о скорости построения этого плана12 мар. 2018 г. 19:16 пользователь "Andrey Lizenko" <lizenko79@gmail.com> написал:Первое, что в голову приходит - вы статистику обновляли после апгрейда?2018-03-12 17:11 GMT+01:00 Nik Ludmirsky <ludmirsky@gmail.com>:Коллеги,после обновления до 9.6 стали медленно исполнятся некоторые запросы.
Попытался проанализировать и вижу, что в некоторых случаях на достаточно простых запросах долго строится execution plan.
Для примера вот запрос:SELECTT1.*FROM _Reference54 T1LEFT OUTER JOIN _InfoRg4210 T2ON T1._Fld9680RRef = T2._Fld4213RRefWHERE ((T1._Fld5384 = 0)) AND ((T1._IDRRef = '\202\260\360yYn\310\234\021\346\376U\244\354w\227'::bytea)) EXPLAIN ANALYSE показывает "Planning time: 1425.054 ms" при том, что "Execution time: 126.907 ms".В чем проблема? Как можно ускорить планирование?Nested Loop Left Join (cost=0.98..13291.41 rows=5619 width=237) (actual time=40.649..126.838 rows=1 loops=1)-> Index Scan using _reference54hpk on _reference54 t1 (cost=0.43..2.65 rows=1 width=237) (actual time=0.066..0.068 rows=1 loops=1)Index Cond: ((_fld5384 = '0'::numeric) AND (_idrref = '\202\260\360yYn\310\234\021\346\376U\244\354w\227'::bytea)) -> Index Only Scan using _inforg4210_bydims_rrrrr on _inforg4210 t2 (cost=0.55..13288.75 rows=1 width=19) (actual time=40.578..126.764 rows=1 loops=1)Index Cond: (_fld4213rref = t1._fld9680rref)Heap Fetches: 0"Planning time: 1425.054 msExecution time: 126.907 ms----С уважением,
Людмирский Николай--Regards, Andrei Lizenko
Regards, Andrei Lizenko