У меня есть пустая родительская таблица, наследуемая сотнями дочерних таблиц, все с той же схемой. Детские таблицы соответствуют датам файлов, которые поступают ежедневно. Таблицы имеют индекс, построенный на столбце time (и другие) и представляют данные событий. Ни один ребенок таблица с датой файла t не имеет ряд с time > tОсмотрите блокировки, запрошенные запросом out_of_shared_memory
Я запрашивая родительскую таблицу и получить out_of_shared_memory ошибку, так как количество замков превышает мой max_locks_per_transaction * (max_connections + max_prepared_transactions) предел.
Есть ли способ определить, какие дочерние таблицы и связанные с ними отношения требуют блокировки без его запуска? Или это просто все отношения, которые появляются в EXPLAIN (expr)? Я ограничиваю time не старше 30 дней, что, по моему мнению, уменьшит необходимость блокировки дочерних таблиц с датой файла менее 30 дней назад. Тем не менее, мой план запроса демонстрирует, что сканирование индекса выполняется во всех индексах дочерних таблиц time, поэтому мне интересно, действительно ли они заблокированы после сканирования (предположительно) не возвращают соответствующие строки.
Редактировать: Я должен отметить, что я управляю 9.4 через Amazon RDS. Я знаю, что могу отбросить старые дочерние таблицы, которые мне больше не нужны, или увеличить max_locks_per_transaction, но хотелось бы проверить, есть ли способ сделать мой запрос более умным.