Очень длинное простое объяснение postgresql (без анализа)

#postgresql #amazon-aurora #explain #postgresql-11

#postgresql #амазонка-аврора #объяснять #postgresql-11

Вопрос:

Чтобы понять, почему запрос был медленным, я провел его анализ… Хотя я не понимаю, почему запрос на объяснение занимает несколько минут.. (ну, мне пришлось отменить запрос на объяснение, потому что я не получил результат после того, как дал ему поработать несколько минут).

Версия сервера Postgresql : PostgreSQL 11.8 на x86_64-pc-linux-gnu, скомпилированный gcc (GCC) 4.9.3, 64-разрядный

так что объяснение было таким :

 explain select myfield from my_view where myconditions ;  

без анализа, многословия и т. Д..

При запросе pg_stat_activity я не видел никакой «блокировки» (wait_event_type и wait_event, где «null»), и состояние было «активным» для этого объяснения.

Это рабочий сервер, на котором был обработан текущий трафик (без проблем) — ну, tranfic не использует этот запрос. При выполнении запроса, который я хочу проанализировать, мне нужно подождать более 10 минут, чтобы получить ответ.

Запрос выполняется в представлении, которое создает «объединение» между одной горячей таблицей и эквивалентным по структуре, но разделенным. Размер горячего стола составляет около 300 ГБ, а разделенный стол имеет около 20 детей. Общий размер разделов составляет около 600 ГБ, с разделом от 5 ГБ до 100 ГБ.

Есть ли что-то, что могло бы объяснить, почему план не возвращается сразу же ?

  • ПРАВКА : при выполнении объяснения только на горячем столе ответ дается немедленно. при выполнении объяснения только в таблице разделов ответ также был очень быстрым. в то время как, что очень долго, это объяснение с запросом, где часть » от «находится в представлении, которое создает «объединение» в этих двух таблицах (горячая таблица и разделенная таблица)

ПРАВКА 2 : результат объяснения (подробного, краткого) запроса, как и было запрошено (я сделал все возможное, чтобы анонимизировать запрос, не изменяя важную часть-я не изменил никаких мер)

 Hash Left Join (cost=8.09..11.82 rows=2 width=585)  Output: a, b, c, rid, creation_date  Inner Unique: true  Hash Cond: (traffic.msg_action = ddd.rid)  -gt; Hash Right Join (cost=6.88..10.54 rows=2 width=441)  Output: traffic.a, traffic.b, traffic.c, traffic.rid, traffic.creation_date  Hash Cond: (sys_sysapp_sys_application.sysapp_app_id = traffic.msg_app_id)  Filter: (sys_sysapp_sys_application.sysapp_del_date IS NULL)  -gt; Seq Scan on general_sys_sys.sys_sysapp_sys_application (cost=0.00..3.19 rows=119 width=25)  Output: f1, f2, f3  -gt; Hash (cost=6.86..6.86 rows=2 width=428)  Output: traffic.a, traffic.b, traffic.c, traffic.rid, traffic.creation_date  -gt; Append (cost=0.57..6.86 rows=2 width=428)  -gt; Index Scan using idx_traffic_creation_date_210713 on myappli.traffic (cost=0.57..2.60 rows=1 width=465)  Output: traffic.a, traffic.b, traffic.c, traffic.rid, traffic.creation_date  Index Cond: ((traffic.msg_creation_date gt;= '2021-08-01 05:25:00'::timestamp without time zone) AND (traffic.msg_creation_date lt;= '2021-08-01 05:34:59'::timestamp without time zone))  Filter: (((traffic.c)::text = '777'::text) AND (traffic.m = '28'::smallint) AND (traffic.t = ANY ('{1,2,3}'::smallint[])))  -gt; Index Scan using traffic_histo_y2021m08_msg_creation_date_idx on myappli_histo.traffic_histo_y2021m08 (cost=0.43..4.25 rows=1 width=392)  Output: traffic_histo_y2021m08.a, traffic_histo_y2021m08.b, traffic_histo_y2021m08.c, traffic_histo_y2021m08.rid, traffic_histo_y2021m08.creation_date,   Index Cond: ((traffic_histo_y2021m08.msg_creation_date gt;= '2021-08-01 05:25:00'::timestamp without time zone) AND (traffic_histo_y2021m08.msg_creation_date lt;= '2021-08-01 05:34:59'::timestamp without time zone))  Filter: (((traffic_histo_y2021m08.msg_c)::text = '777'::text) AND (traffic_histo_y2021m08.msg_type = ANY ('{1,2,3}'::smallint[])))  -gt; Hash (cost=1.09..1.09 rows=9 width=34)  Output: ddd.resac_label, ddd.rid  -gt; Seq Scan on general_sys_sys.sys_resac_res_action ddd (cost=0.00..1.09 rows=9 width=34)  Output: ddd.r, ddd.rid  Planning Time: 1844806.025 ms (26 rows)  

ПРАВКА 3 : Представление «my_view», выполняемое моим запросом, выглядит следующим образом

 create or replace my_view as  select a, b, c from myappli.traffic UNION ALL select a, b, c from myappli_histo.traffic_partitionned_parent_table  

И запрос обычно выглядит так

 select a, b, c from my_view where c between '20210801 000000' and '20210802 000000'  

Комментарии:

1. Либо разделов очень много, поэтому планировщику приходится работать очень долго, либо есть ошибка, либо есть повреждение данных.

2. Можете ли вы показать нам план, созданный с помощью explain (verbose, summary) ... ? Это покажет дополнительную информацию о времени планирования

3. спасибо — я вставил результат плана исполнителя, как и было запрошено-для первого вопроса есть только 20 разделов или около того.

4. @a_horse_with_no_name — Я также добавил запросы и структуру представления

5. Текущая версия исправления ошибки v11-REL_11_14. Возможно, ваша проблема была устранена за последние 18 месяцев.