2

我的团队正在考虑从 9.1 切换到 9.4，作为零件评估，我们想衡量INSERT INTO TABLE ...在有3-4固定长度类型的列（例如INT，DOUBLE PRECISION. 我们使用的是未批处理INSERT的，表格是logged和not temporary。fsync设置为on。

Q0：有没有理由认为这9.4会比9.1这个特定的声明更快？

例如基于改进的 WAL 性能：

https://momjian.us/main/writings/pgsql/features.pdf

显然，最好的答案是去检查我们的数据并进行实验，但让我们允许一些猜测。

Q1 : 有你知道的绩效评估吗？

Q2：INSERT被占用了WAL多少？

服务器上的设置（从9.1配置文件中逐字复制）

#fsync = off
#synchronous_commit = on
#wal_sync_method = fsync
#full_page_writes = on
#wal_buffers = -1
#wal_writer_delay = 200ms

shared_buffers = 15GB
temp_buffers = 1024MB
work_mem = 1024MB
4

1 回答 1

3

您提供的链接基于第 E.2.3.1.2 节中的信息。一般性能- 顺便说一句，读起来很棒。根据您建议的测试，我预计不会有任何真正的性能差异，因为您不会利用并行或部分写入（关于 wal 文件）。也就是说，您将来可能会遇到这种情况。此外，9.4（好吧，实际上是 9.1 之后）提供了许多有用的工具和性能增强，在我看来，这证明了从 9.1 切换到 9.4 的合理性。例如，从 9.2 开始，JSON 现在是一种数据类型，可以进行仅索引扫描，并且内存中的排序提高了 25%。9.3 引入了物化视图（在 9.4 中具有并发刷新）和可更新的“简单”（在 9.4 中定义略微扩展）视图。在 9.4 中，增强了聚合并定义了 ALTER SYSTEM（更改配置设置的能力（进入最后读取的 postgresql.auto.config，

值得注意的是，默认日志记录也发生了变化。例如，在创建表时，您将不会收到有关隐式索引和序列创建的消息（将日志级别设置为 DEBUG1 以进行修复——尽管当我从 9.1 切换到 9.3 时，特别是在讲座期间，这让我发疯了）。

关于问题 1，我会运行TPC基准测试（C 和 VMS 是唯一不免费的）。对于问题 2，这实际上取决于您的 wal 设置，但是根据我从您的配置文件中看到的内容，版本性能无关紧要。我还会在您的系统上运行 pgtune（下面的链接），以确保您的配置文件在测试之前尽可能优化。

与其他评论者一样，只需构建它，看看会发生什么。直接插入可能不会有太大差异（如果有的话），所以我会尝试大型、多表连接、大量排序和大量事务模拟（例如，大量插入、更新和删除 - 只需使用 plpgsql简单）- TCP 查询也将在性能测试方面做得很好。

链接：

要查找“新增功能”PostgreSQL wiki 页面，请将版本号添加到以下URL的末尾。

您可以在 pgtune.leopard.in.ua 找到 pgtune 的 GUI 版本；独立下载从 pgfoundry 被击中或错过，因为它似乎总是被关闭。

于 2015-04-26T02:29:17.623 回答