Re: Postgres 9.6. Большое planning time в простом запросе

Не ваш случай?

https://stackoverflow.com/questions/45069283/postgres-how-to-debug-why-planning-time-is-too-long

The problem is that you have too many partitions.

2018-03-12 18:38 GMT+01:00 Nik Ludmirsky <ludmirsky(at)gmail(dot)com>:

> Конечно, но речь не о качестве плана, а о скорости построения этого плана
>
> 12 мар. 2018 г. 19:16 пользователь "Andrey Lizenko" <lizenko79(at)gmail(dot)com>
> написал:
>
> Первое, что в голову приходит - вы статистику обновляли после апгрейда?
>>
>> 2018-03-12 17:11 GMT+01:00 Nik Ludmirsky <ludmirsky(at)gmail(dot)com>:
>>
>>> Коллеги,
>>>
>>> после обновления до 9.6 стали медленно исполнятся некоторые запросы.
>>> Попытался проанализировать и вижу, что в некоторых случаях на достаточно
>>> простых запросах долго строится 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
>>>
>>> ----
>>> С уважением,
>>> Людмирский Николай
>>>
>>>
>>
>>
>> --
>> Regards, Andrei Lizenko
>>
>

--
Regards, Andrei Lizenko