funbringer
commented
7 years ago Добрый день, @NikitinNikolay
Прошу прощения за задержку. Давайте попробуем разобрать ваш пример (на это у меня ушло некоторое время, т.к. я не сразу заметил, что для генерации данных таблиц используется pgcrypto, и все пришлось переделывать).
Второй возможный баг: Почему-то таблица tab_child присоединяется к первой через шаги Merge Append, Materialize и Merge Join и делает полный перебор партиций, хотя мне кажется тут был бы более уместен Ваш шаг RuntimeAppend, но он почему-то не выбирается.
Честно признаться, меня смущает, что вы называете это поведение багом. В теории, все планы имеют свою стоимость, и именно она определяет план, который будет выбран и выполнен. К сожалению, нет простого способа вывести перечень всех возможных планов, однако мы можем отключить неугодные узлы и посмотреть, что из этого выйдет.
explain (analyse, costs off)
select *
from public.tab_parent p
inner join public.tab_child c on c.partition_id = p.partition_id and c.parent_id = p.parent_id
where p.partition_id in (2, 3)
limit 100;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------
Limit (actual time=0.106..0.640 rows=100 loops=1)
-> Merge Join (actual time=0.104..0.627 rows=100 loops=1)
Merge Cond: (p.parent_id = c.parent_id)
Join Filter: (p.partition_id = c.partition_id)
-> Merge Append (actual time=0.046..0.123 rows=53 loops=1)
Sort Key: p.parent_id
-> Index Scan using tab_parent_2_pkey on tab_parent_2 p (actual time=0.027..0.051 rows=27 loops=1)
Filter: (partition_id = ANY ('{2,3}'::numeric[]))
-> Index Scan using tab_parent_3_pkey on tab_parent_3 p_1 (actual time=0.018..0.046 rows=27 loops=1)
Filter: (partition_id = ANY ('{2,3}'::numeric[]))
-> Materialize (actual time=0.050..0.283 rows=156 loops=1)
-> Merge Append (actual time=0.047..0.241 rows=156 loops=1)
Sort Key: c.parent_id
-> Index Scan using tab_child_1_parent_id_idx on tab_child_1 c (actual time=0.015..0.039 rows=57 loops=1)
-> Index Scan using tab_child_2_parent_id_idx on tab_child_2 c_1 (actual time=0.014..0.039 rows=43 loops=1)
-> Index Scan using tab_child_3_parent_id_idx on tab_child_3 c_2 (actual time=0.014..0.045 rows=58 loops=1)
Planning time: 1.305 ms
Execution time: 0.767 ms
(18 rows)
/* отключаем MergeJoin в целях эксперимента */
set enable_mergejoin = f;
explain (analyse, costs off)
select *
from public.tab_parent p
inner join public.tab_child c on c.partition_id = p.partition_id and c.parent_id = p.parent_id
where p.partition_id in (2, 3)
limit 100;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------
Limit (actual time=0.064..0.902 rows=100 loops=1)
-> Nested Loop (actual time=0.063..0.891 rows=100 loops=1)
-> Append (actual time=0.015..0.054 rows=52 loops=1)
-> Seq Scan on tab_parent_2 p (actual time=0.015..0.049 rows=52 loops=1)
Filter: (partition_id = ANY ('{2,3}'::numeric[]))
-> Seq Scan on tab_parent_3 p_1 (never executed)
Filter: (partition_id = ANY ('{2,3}'::numeric[]))
-> Custom Scan (RuntimeAppend) (actual time=0.009..0.011 rows=2 loops=52)
Prune by: (p.partition_id = c.partition_id)
-> Index Scan using tab_child_2_parent_id_idx on tab_child_2 c_1 (actual time=0.008..0.010 rows=2 loops=52)
Index Cond: (parent_id = p.parent_id)
Filter: (p.partition_id = partition_id)
Planning time: 0.953 ms
Execution time: 0.981 ms
(14 rows)Можно заметить, что времена планирования и исполнения довольно похожи: они определенно не различаются на порядок. Тем не менее, у обоих планов наблюдается довольно сильный разброс по времени, поэтому имеет смысл вынести запрос в скрипт и пропустить через pgbench:
# MergeJoin
transaction type: bench.sql
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
duration: 200 s
number of transactions actually processed: 135644
latency average = 1.473 ms
latency stddev = 0.157 ms
tps = 678.215636 (including connections establishing)
tps = 678.221930 (excluding connections establishing)
# NestedLoop + RuntimeAppend
transaction type: bench.sql
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
duration: 200 s
number of transactions actually processed: 126413
latency average = 1.581 ms
latency stddev = 0.242 ms
tps = 632.059027 (including connections establishing)
tps = 632.063123 (excluding connections establishing)Можно заметить, что комбинация NestedLoop + RuntimeAppend на этот раз проявила себя хуже, чем MergeJoin, хотя, честно говоря, при таком времени исполнения запроса это абсолютно не важно, сгодился бы любой план. Разница практически не видна.
Возможно, вы упростили какой-то реальный кейс, в котором у вас выбирается неудачный план? Если так, то будет лучше, если вы предоставите нам исходные данные (кол-во партиций, кол-во строк, возможно, что-нибудь еще).
А вот pg_pathman похоже в качестве слагаемых почему-то берёт теоретические размеры записей из родительских таблиц tab_parent и tab_child.
Абсолютно верно, и мы не видим способа эта исправить (по крайней мере, пока не видим). При обычном наследовании считается средняя длина для всех партиций, в то время как pathman вынужден пользоваться стандартной оценкой для одиночной таблицы.
На первый взгляд, это не должно приводить к выбору неправильного плана, т.к. аналогичная оценка попадает во все рассматриваемые планы.
NikitinNikolay
Здравствуйте!
Нашёл баг при вычислении ширины возвращаемых строк, и возможно второй при формировании плана. У меня это всё проявляется на Red Hat Server 6.7, Postresql 9.6.3 и pg_pathman 1.4.2. Стенд делается следующими командами:
Вывод плана запроса:
Первый баг: Хорошо видно, что у Merge Append width=84, у Materialize width=90, а у шага который их соединяет Merge Join width=596. Без pg_pathman ширина результирующей строки равна сумме ширин строк предшествующих шагов. А вот pg_pathman похоже в качестве слагаемых почему-то берёт теоретические размеры записей из родительских таблиц tab_parent и tab_child.
Второй возможный баг: Почему-то таблица tab_child присоединяется к первой через шаги Merge Append, Materialize и Merge Join и делает полный перебор партиций, хотя мне кажется тут был бы более уместен Ваш шаг RuntimeAppend, но он почему-то не выбирается. К сожалению, я не знаю как оттрассировать в постгрес выбор плана и не могу определить причину почему выбирается именно этот план.
С уважением, Никитин Николай.