Q1:Não há limite explícito nos documentos . Na prática, algumas operações são O(n) no número de tabelas; espere que os tempos de planejamento aumentem e problemas com coisas como autovacuum à medida que você chega a muitos milhares ou dezenas de milhares de tabelas em um banco de dados.

Q2:Depende da consulta. Geralmente, grandes sindicatos são uma má ideia. A herança de tabela funcionará um pouco melhor, mas se você estiver usando constraint_exclusion resultará em tempos de planejamento muito maiores.

Ambas as perguntas sugerem um problema subjacente com seu design. Você não deve precisar um grande número de mesas e sindicatos gigantes.

Indo pelo comentário na outra resposta, você realmente deveria estar criando apenas algumas tabelas. Você parece querer criar uma tabela por número de telefone, o que não faz sentido, e criar visualizações por número em cima disso. Não faça isso, está modelando incorretamente os dados e tornará mais difícil, não mais fácil, trabalhar com eles. Índices, cláusulas where e junções permitirão que você use os dados com mais eficiência quando estiverem estruturados logicamente em algumas tabelas. Sugiro estudar modelagem relacional básica.

Se você tiver problemas de escalabilidade posteriormente, consulte particionamento , mas você não precisará de milhares de tabelas para isso.