相关疑难解决方法(0)

在 Ubuntu 12.04 上使用 PG 9.1。

目前，我们在数据库上运行大量 UPDATE 语句最多需要 24 小时，它们的形式如下：

UPDATE table
SET field1 = constant1, field2 = constant2, ...
WHERE id = constid

（我们只是覆盖由 ID 标识的对象的字段。）这些值来自外部数据源（尚未在数据库中的表中）。

每个表都有几个索引，没有外键约束。直到最后都没有提交。

导入pg_dump整个数据库的一个需要 2 小时。这似乎是我们应该合理定位的基线。

除了生成以某种方式重建数据集以供 PostgreSQL 重新导入的自定义程序之外，我们是否可以做些什么来使批量 UPDATE 性能更接近导入的性能？（这是一个我们认为日志结构合并树处理得很好的领域，但我们想知道是否可以在 PostgreSQL 中做任何事情。）

一些想法：

• 删除所有非 ID 索引然后重建？
• 增加 checkpoint_segments，但这真的有助于维持长期吞吐量吗？
• 使用这里提到的技术？（将新数据加载为表，然后“合并”在新数据中找不到 ID 的旧数据）

基本上有很多事情要尝试，但我们不确定什么是最有效的，或者我们是否忽略了其他事情。我们将在接下来的几天里进行实验，但我们想我们也会在这里问。

我确实在表上有并发负载，但它是只读的。

我在 Ubuntu 上使用 PostgreSQL 9.1。VACUUM ANALYZE仍然推荐预定，还是 autovacuum 足以满足所有需求？

如果答案是“视情况而定”，那么：

• 我有一个较大的数据库（30 GiB 压缩转储大小，200 GiB 数据目录）
• 我对数据库做 ETL，每周导入接近 300 万行
• 变化最频繁的表全部继承自一个主表，主表中没有数据（数据按周分区）
• 我创建每小时汇总，并从那里创建每日、每周和每月报告

我问是因为预定的时间VACUUM ANALYZE会影响我的报告。它运行了 5 个多小时，本周我不得不杀死它两次，因为它影响了常规的数据库导入。check_postgres不会报告数据库有任何显着膨胀，所以这不是真正的问题。

从文档中，autovacuum 也应该处理事务 ID 环绕。问题是：我还需要一个VACUUM ANALYZE吗？

我有一个与性能相关的问题。假设我有一个名为 Michael 的用户。进行以下查询：

UPDATE users
SET first_name = 'Michael'
WHERE users.id = 123

查询是否会实际执行更新，即使它被更新为相同的值？如果是这样，我该如何防止它发生？

n_live_tupand n_dead_tupin pg_stat_user_tablesor是什么意思pgstattuple？

昨晚将我们的数据库从 9.3.5 升级到 9.4.1 后，服务器遇到了高 CPU 峰值。升级是通过 pg_dump 完成的。于是把数据库转成SQL，再导入9.4。

在 CPU 峰值期间，日志中有很多这样的消息：

process X still waiting for ExclusiveLock on extension of relation Y of database Z 
after 1036.234 ms

和：

process X acquired ExclusiveLock on extension of relation Y of database Z
after 2788.050 ms

看起来可疑的是，有时在完全相同的毫秒内有几个完全相同的关系号的“获取”消息。

为什么 Postgres 会在同一毫秒内将一个表增长两次？它可能是一个具有高填充因子的索引吗？

欢迎任何有关如何解决此问题的建议。

PS 我也在Postgres 邮件列表上问过这个问题，如果不行，请告诉我。

我在 Postgres 8.2.15 数据库中有一个表。该表膨胀到近 25GB，但在运行完真空和集群后，表的大小显着变小，远低于 1GB。几周后，它又回到了 3.5GB 并且还在攀升。

这不是一个经常删除的表，所以我不知道是什么导致了膨胀。

这仅发生在单个表上。我有一个单独的、结构相同的数据库，为相同的软件提供服务；该数据库中的表没有显示任何膨胀。

有任何想法吗？