摄取性能对于许多常见的PostgreSQL用例至关重要，包括应用监控、应用分析、物联网监控等等。 虽然数据库长期以来都有时间字段，但是这些用例收集的数据类型有一个关键的区别:与标准的关系“业务”数据不同，变更被视为 插入，而不是覆盖-换句话说，每个新值都变成一个 新的 数据库中的行，而不是用最新的值替换该行的先前值hfs。

如果您在需要保留所有数据的情况下运行。 覆盖过去的值，优化数据库接收新数据的速度变得至关重要。

我们有很多为自己和社区成员优化性能的经验，我们已经将我们的最佳技巧分成了两类。 首先，我们概述了一些对改进PostgreSQL有用的技巧。 之后，我们概述了几个特定于时间尺度数据库的特性。

以下是在普通PostgreSQL中提高接收性能的一些最佳实践:

拥有正确的索引可以加快您的查询速度，但它们不是万灵药。 增量维护每个新行的索引需要额外的工作。 检查您在表上定义的索引数量(使用命令插入带有最近时间戳的新行将被写入内存中已经存在的这些块和索引。，并确定它们的潜在查询优势是否超过存储和插入开销。 因为每个系统都是不同的，所以没有任何硬性的规则或“神奇数字”的索引——只要合理就行。

有时需要从一个表到其他关系表建立外键(FK，这是一个无序或回填的写入—对应于较旧区块(及其索引选择块_表、范围、总大小的磁盘页面将需要从磁盘读入。。 当您有FK约束时，每个插入通常需要从您引用的表中读取，这可能会降低性能。 考虑一下你是否可以反规范化你的数据——我们有时会看到FK约束的非常极端的使用，从“优雅”的角度而不是从工程权衡的角度来做。

开发人员经常被训练在数据库表中指定主键，许多表单都喜欢它们。 然而，许多用例——包括常见的监控或时序应用——并不需要它们，因为每个事件或传感器读数都可以简单地作为单独的事件记录下来，方法是在写入期间将其插入超表的当前块的尾部。

如果以其他方式定义了UNIQUE约束，则该插入可能需要进行索引查找，以确定该行是否已经存在，这将对插入的速度产生不利影响。

虽然这是一种不总是需要的更高级的优化，但是如果您的磁盘成为瓶颈，您可以通过为数据库的预写日志和数据使用单独的磁盘(表空间)来进一步提高吞吐量。

有时，开发人员会在磁盘速度较慢的环境中部署他们的数据库，无论是因为硬盘性能不佳、远程存储区域网络还是其他类型的配置。 因为在插入行时，数据会在事务完成之前持久地存储到预写日志中，所以速度慢的磁盘会影响插入性能。 要做的一件事是使用命令检查您的磁盘IOPS。

阅读测试:

SQLcs