Q1：the docs中没有明确的限制。在实际中，一些操作在表的数量上是O（n）的;预计计划时间会增加，当数据库中有数千或数万个表时，会出现自动真空等问题。
Q2：这取决于查询。总的来说，大型工会是个坏主意。表继承会稍微好一点，但如果使用constraint_exclusion，则会导致规划时间大大增加。
这两个问题都暗示了您的设计存在潜在的问题。你不应该 * 需要 * 大量的表，和巨大的工会。
根据另一个答案中的注解，您实际上应该只创建几个表。您似乎想为每个电话号码创建一个表，这是荒谬的，并在此基础上为每个号码创建视图。不要这样做，这是对数据的错误建模，会使其更难，而不是更容易使用。索引、where子句和连接将允许您在数据逻辑结构化为几个表时更有效地使用数据。我建议学习基本的关系建模。
如果以后遇到可伸缩性问题，可以查看partitioning，但不需要数千个表。

从实际意义上讲，两者都没有限制。
数据库可以容纳的表数受磁盘系统上的空间限制。但是，如果数据库中的表超过几千个，则很可能表示对应用程序域的分析不正确。工会也是如此：如果您必须联合多个表，那么您可能应该查看表结构。
一个可能发生这种情况的实际场景是Postgis：拥有许多具有相似属性的表，这些表可以在单个视图中连接（这是Postgis IMHO设计中的一个缺陷），但通常会在应用程序端进行处理（例如，a GIS）。
您能解释一下您的场景吗？在这个场景中，您需要在一次扫描中查询大量的表。

postgresql中的表/关系的数量似乎有一个硬性限制。每个数据库最多可以有1，431，650，303个关系。还有其他硬限制，您可以看到所有这些限制here