mar*_*kus 7 postgresql performance index index-tuning query-performance
我们在 Postgres 9.2.10 数据库中有一个大约有 20 列的表。为了在某些SELECT
查询上获得更好的性能,我们计划在数据类型为 的列上添加索引timestamp
。由于索引也会降低插入的性能,我们做了以下性能测试:
我们在表中插入了 500 万条记录。那是最大值。我们期望在生产中的记录数。然后我们测量了在时间戳列上插入有索引和没有索引的 10000 条记录的时间。这是我们每天预期的最大插入次数,峰值每秒不超过 5 次插入。
结果如下:
至少对于本次测试,该指数仅略微降低了性能。对于我们的要求,我没有看到添加索引的问题。
但这只是实验室环境中的一项测试,在生产数据库上运行时是否还有其他陷阱?我们是否会遇到INSERT
在特定情况下突然需要超过 5 秒的情况?
不,小列上的基本 btree 索引通常维护起来很便宜。当然,当表因死行而积累了一些膨胀时,它会稍微昂贵一些,但差异应该很小。并且您必须考虑在磁盘上为索引提供额外的存储空间。
有件事似乎值得一提:以任何方式对索引中涉及的列进行更新都不能使用热更新(“仅堆元组”),因此这可能会增加更改索引列的更新的一些成本。但尽管如此,这只会阻止一项内部优化,没什么大不了的。并且仅当您将该专栏包含在更新中时才相关。
归档时间: |
|
查看次数: |
4172 次 |
最近记录: |