我意识到，根据Pg文档（http://www.postgresql.org/about/），可以在表中存储无限数量的行。但是，对于可用的行数（如果有的话），“经验法则”是什么？
背景：我想为1300万个细胞存储几十年的每日读数。这可以达到13 M *（366 | 365）* 20~9.5e10，或95 B行（实际上，大约120 B行）。
因此，使用表分区，我设置了一个主表，然后按年继承表。这会将行分为每个表约5.2 B行。
每行是9个SMALLINT，两个是INT，因此，26个字节。除此之外，每行23字节的Pg开销，每行得49个字节。因此，每张桌子，没有任何PK或任何其他指数，将重约0.25 TB。
对于初学者，我只创建了上述数据的一部分，即只有大约250,000个单元格。我必须做一堆调整（创建适当的索引等），但现在的性能真的很糟糕。此外，每次我需要添加更多数据时，我都必须删除密钥并重新创建它们。保存的优点是，一旦加载了所有内容，它将是一个只读数据库。
有什么建议吗？任何其他分区策略？
答案 0 :(得分：48)
这不只是“一堆调整（索引等）”。这是至关重要的，也是必须的。
你发布了一些细节，但试试吧。
规则是：尝试找到最常用的工作集。看看它是否适合RAM。为其优化硬件，PG / OS缓冲区设置和PG索引/群集。否则查找聚合，或者如果它不可接受并且您需要完全随机访问，请考虑硬件可以在合理的时间内为您扫描整个表。
你的桌子有多大（千兆字节）？它与总RAM相比如何？您的PG设置是什么，包括shared_buffers和effective_cache_size？这是专用服务器吗？如果你有一个250-gig的表和大约10 GB的RAM，这意味着你只能满足表的4％。
是否有常用于过滤的列，例如州或日期？你能使用最常用的工作装置（比如上个月）吗？如果是这样，请考虑对这些列进行分区或聚类，并明确索引它们。基本上，您正在尝试确保尽可能多的工作集适合RAM。
如果桌面不适合RAM，请不惜一切代价扫描桌面。如果您确实需要绝对随机访问，那么唯一可以使用的方法就是复杂的硬件。您需要一个持久的存储/ RAM配置，它可以在合理的时间内读取250 GB。