pg_dump и pg_restore и pg_upgrade на самом деле хуже, чем O (N ^ 2). Раньше это была огромная проблема, хотя в последних версиях константа этого N ^ 2 была уменьшена до такой низкой, что для 100 000 таблиц этого, вероятно, недостаточно, чтобы быть вашей самой большой проблемой. Однако есть и худшие случаи, например, для таблиц дампа может быть O (M ^ 2) (может быть, M ^ 3, точные детали я больше не помню) для каждой таблицы, где M - количество столбцов в таблице. Это применимо только тогда, когда столбцы имеют проверочные ограничения или значения по умолчанию или другую дополнительную информацию помимо имени и типа. Все эти проблемы особенно неприятны, когда у вас нет проблем с эксплуатацией, чтобы предупредить вас, но вдруг обнаруживается, что вы не можете выполнить обновление в течение разумного периода времени.
Некоторые физические методы резервного копирования, такие как barman с использованием rsync также равны O (N ^ 2) в количестве файлов, что, по крайней мере, равно количеству таблиц.
Во время обычной работы сборщик статистики может стать большим узким местом. Каждый раз, когда кто-то запрашивает обновленную статистику для некоторой таблицы, он должен записать файл, охватывающий все таблицы в этой базе данных. Записать это - O (N) для таблиц в этой базе данных. (Раньше было хуже, выписывая один файл для экземпляра while, а не только базу данных). Это может быть еще хуже в некоторых файловых системах, которые при переименовании одного файла поверх существующего неявно синхронизируют файл, поэтому размещение его в ОЗУ dis c может как минимум улучшить это.
Автовакуум работает над каждой таблицей (примерно один раз за время autovacuum_naptime), чтобы решить, нужно ли их пылесосить, поэтому огромное количество таблиц может замедлить это. Это также может быть хуже, чем O (N), потому что для каждой таблицы есть вероятность, что она запросит обновленную статистику по ней. Хуже того, он может при этом блокировать всех одновременных работников автоочистки (эта последняя часть исправлена в бэк-патче для всех поддерживаемых версий).
Другая проблема, с которой вы можете столкнуться, заключается в том, что каждый сервер базы данных поддерживает кэш метаданных в каждой таблице. (или другой объект) он получил доступ в течение своей жизни. Механизм для истечения срока действия этого кэша отсутствует, поэтому, если каждое соединение касается огромного количества таблиц, оно начнет занимать много памяти и по одной копии для каждого бэкэнда, поскольку оно не используется совместно. Если у вас есть диспетчер соединений, который держит соединения открытыми на неопределенный срок, это может действительно сложиться, поскольку каждое соединение живет достаточно долго, чтобы касаться многих таблиц.