问PostgreSQL中表数的O(n)是什么操作？

EN

pg_dump、pg_restore和pg_upgrade实际上比这更糟糕，是O(N^2)。这曾经是一个巨大的问题，尽管在最近的版本中，N^2上的常数已经降到了如此之低，以至于对于100000个表来说，它可能还不够大。但是，还有更糟的情况，比如转储表可能是O(M^2) (可能是M^3，我不再记得每个表的确切细节了)，其中M是表中的列数。这只适用于列有检查约束或默认值或名称和类型以外的其他附加信息。当您没有操作问题来警告您，但是突然发现您无法在合理的时间范围内升级时，所有这些问题都是特别严重的。

一些物理备份方法，比如使用barman的rsync，在文件数量上也是O(N^2)，这至少和表的数量一样多。

在正常操作期间，统计数据收集器可能是一个很大的瓶颈。每当有人请求更新某个表上的统计数据时，它都必须写出一个涵盖该数据库中所有表的文件。该数据库中的表的O(N)就是这样写出来的。(过去更糟的是，为while实例而不仅仅是数据库编写了一个文件)。在某些文件系统上，这可能会变得更糟，当在现有文件的顶部重命名一个文件时，会隐式地对文件进行同步，因此将其放入RAM磁盘至少可以改善这一点。

自动真空工作人员循环遍历每个表(大约每个autovacuum_naptime一次)，以确定是否需要对其进行真空，因此大量的表可以减缓这一速度。这也可能比O(N)更糟糕，因为对于每个表，它都有可能请求更新的统计数据。更糟糕的是，它可以同时阻止所有并发的自动真空工作人员(最后一部分修复在所有受支持版本的后台补丁中)。

您可能会遇到的另一个问题是，每个数据库后端都在其生存期内访问的每个表(或其他对象)上维护一个元数据缓存。没有机制来终止这个缓存，所以如果每个连接都接触到大量的表，那么它将开始消耗大量的内存，并且每个后端都有一个副本，因为它是不共享的。如果您有一个可以无限期地保持连接打开的连接池，那么当每个连接存在足够长的时间来访问多个表时，这实际上就会加起来。

pg_dump有一些选项，可能是-s。其他一些选项使得它更多地依赖于数据的大小。