В целом, согласно тем, кого я знаю, кто использовал очень большое количество таблиц (во многих тысячах), накладные расходы на планирование увеличиваются по мере увеличения количества таблиц в БД.Те, кого я знал, у которых была эта проблема, должны были найти решения этой проблемы, но не указали мне, что это были за решения.Что происходит, так это планировщик базы данных, чтобы решить, как лучше всего выполнить запрос, нужно искать информацию на основе таблиц и столбцов, поэтому для этого требуется поиск данных в системных каталогах, которые со временем становятся все более раздутыми.Это влияет на каждый запрос в плановое время.
Основная проблема заключается в том, что при планировании необходимо учитывать данные таблиц (требующих поиска данных в таблицах), а также столбцов и столбцов.Интересно, что pg_class имеет индекс для oid и индекс для relnamespace, но не для relname, и вы не можете его легко создать.Единственные индексы в системных таблицах - это УНИКАЛЬНЫЕ ограничения, и поэтому я не вижу, как, кроме изменения системных каталогов (на уровне источника или предоставления вам разрешения на это), вы можете решить эту проблему.
Я также ожидал бы, что производительность будет медленно снижаться, поэтому вы не можете просто установить для этого жесткие ограничения.Следовательно, это зависит от приемлемой производительности при данной рабочей нагрузке.
Если у вас столько таблиц, я бы посмотрел, сколько из них можно разбить на другие базы данных.
tl;dr: ожидайте проблем с производительностью с очень большим количеством таблиц.Будьте готовы проявить творческий подход к их решению.