我的团队正在考虑从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:WAL拿走了多少INSERT
服务器上的设置(从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发布于 2015-04-26 02:29:17
您提供的链接是基于在E.2.3.1.2节。一般性能中找到的信息--顺便说一下,这是一个很好的阅读方式。根据您建议的测试,我不会期望任何真正的性能差异,因为您不会利用并行或部分写入(关于wal文件)。尽管如此,你将来可能会遇到这样的情况。此外,9.4 (好吧,POT9.1真的)提供了许多有用的工具和性能增强,在我看来,有理由将9.1改为9.4。例如,从9.2开始,JSON现在是一种数据类型,Index扫描是可能的,内存中的排序已经提高了25%。9.3介绍了物化视图(同时刷新9.4)和可更新的“简单”视图(定义在9.4中略有扩展)。在9.4中,聚合得到增强并修改系统定义(使用SQL命令更改配置设置(进入最后读取的postgresql.auto.config,确保它覆盖postgresql.config值)。
值得注意的是,默认日志记录也发生了变化。例如,在创建表时,您将不会收到关于隐式索引和序列创建的消息(将日志级别设置为DEBUG1以修复-尽管我从9.1切换到9.3 (尤其是在讲座期间),但这让我发疯了。
关于问题1,我会运行一个TPC基准测试(只有C和VMS不是免费的)。对于问题2,这确实取决于您的wal设置,但是根据我从您的配置文件中看到的,在版本性能方面应该无关紧要。我还会在您的系统上运行pg调优(下面的链接),以确保您的配置文件在测试之前是尽可能优化的。
和其他评论者一样,只需将其构建出来,看看会发生什么。与直接插入可能没有太大的区别,所以我会尝试大型的多表连接、巨大的类型和大量的事务模拟(例如,大量的插入、更新和删除-为了简单起见,只需使用plpgsql )-- TCP查询在性能测试方面也会做得很好。
链接:
要查找“新的内容”PostgreSQL wiki页面,请将版本号添加到以下URL的末尾。
您可以在pgtune.leopard.in.ua上找到pgtune的GUI版本;独立下载是从pg芬兰获得或错过的,因为它似乎总是处于下降状态。
https://stackoverflow.com/questions/29794652
复制相似问题