Maksim Milyutin

> > Почему при JOIN по id (ключ партиционирования) время планирования резко подскакивает до 12 секунд? > Потому что при join получается параметризированный запрос с условием типа `id = $1`,...

@JanMihail тут надо отметить, что долгое время планирования происходит при первом запросе в новой сессии при большом кол-ве секций, что обусловлено прогревом локального кэша конфигурацией секционирования. Вы лучше приложите dump...

@JanMihail спасибо. Ваш случай воспроизводится только в случает множества активных vacuum-процессов в базе? Не могли бы вы собрать профиль ожиданий от [pg_wait_sampling](https://github.com/postgrespro/pg_wait_sampling) для процессa, у которого наблюдается такое долгое время...

@JanMihail спасибо за сэмплы. По ним видно, что у вас contention за мьютексы менеджера блокировок. Чтобы попытаться что-нибудь сделать, нам надо будет воспроизвести вашу нагрузку. Опишите конфигурацию вашей системы и...

> pg_pathman also requires global indexes @funbringer, did you consider the case when global uniqueness of field that's not related with partitioning key is provided via checks on local unique...

@secoint сделайте вызов функции `select set_enable_parent('visitors', false)`. После partition pruning должен заработать

> @maksm90 нет, это не помогает. Покажите вывод `select * from pathman_config_params where partrel = 'visitors'::regclass`

> ```sql > select * from pathman_config_params where partrel = 'visitors'::regclass; > partrel | enable_parent | auto | init_callback | spawn_using_bgw > ----------+---------------+------+---------------+----------------- > visitors | f | t |...

Хм, у меня ваш кейс не воспроизводится. Может проблема в триггере? Он у вас поставлен только на родительскую таблицу?

> Вы ранее дали совет обновиться, потом убрали его. Это не поможет? На вашей версии pg_pathman у меня partition pruning тоже cрабатывает > триггер только на родительской Походу, проблема в...