optimization - 性能优化 - Postgres

Question

我的任务是改进运行缓慢的进程的性能，该进程更新 PostGres 8.3 数据库中的一些数据(在 Solaris 上运行，更新由 Perl 5.8 脚本通过 SOAP 驱动)。大约 50% 的消耗时间我几乎无法控制，因此调整我的 50% 非常重要。

表中通常有大约 4,500,000 行，但我看到它膨胀到大约 7,000,000 行。更新所查询的 ID(不是主要的或唯一的)有不到 9000 个不同的值，并且出现的分布严重偏向于每个 ID 1(中值为 20，最大值为 7000)。

此 ID 上有一个索引，但由于数据如此稀疏，我想知道是否有更好的处理方法。我也在考虑对事物进行一些非规范化(无论如何数据库都不是超规范化的)并将数据拉出到一个单独的表中(可能由触发器控制/维护)以帮助加快速度。

到目前为止，我已经做了一些非常基本的调整(不是每隔 n 秒就对数据库执行 ping 操作以查看它是否存在，没有设置不必要的 session 变​​量等)，这很有帮助，但我真的觉得我缺少一些东西数据……

即使有人说将相关数据提取到一个单独的表中是一个很好/很糟糕的想法，但它确实很有帮助!感谢收到任何其他想法(或进一步的澄清问题)!

查询:

UPDATE tab1 SET client = 'abcd', invoice = 999 
    WHERE id = 'A1000062' and releasetime < '02-11-09'::DATE 
    AND charge IS NOT NULL AND invoice IS NULL AND client IS NULL;

我意识到“不为空”远非理想。 Id 和发票和客户一样被索引(btrees，所以我知道 PostGres 将/应该/可以在那里使用索引)。这是一个非常简单的查询 ...

查询计划(用分析解释):

Bitmap Heap Scan on tab1 (cost=17.42..1760.21 rows=133 width=670) (actual time=0.603..0.603 rows=0 loops=1)
  Recheck Cond: (((id)::text = 'A1000062'::text) AND (invoice IS NULL))
  Filter: ((charge IS NOT NULL) AND (client IS NULL) AND (releasetime < '2009-11-02'::date))
  ->  Bitmap Index Scan on cdr_snapshot_2007_09_12_snbs_invoice  (cost=0.00..17.39 rows=450 width=0) (actual time=0.089..0.089 rows=63 loops=1)
    Index Cond: (((snbs)::text = 'A1000062'::text) AND (invoice IS NULL))
Total runtime: 0.674 ms

我相信 Autovacuum 已启用。没有外键约束，但感谢您的提示，因为我不知道。

我真的很喜欢增加统计值的想法 - 我会马上尝试一下。

Answer 1

您确实需要获得一些查询计划，并编辑您的问题以包含它们。除了帮助找出更好的做事方式外，它们还可以用来轻松衡量改进情况。

---

您可以通过更改 SQL 或调整用于确定查询计划的索引和统计信息来影响性能。

---

一种可能是您有没有支持索引的外键约束。当您创建外键约束时，PostgreSQL 不会自动添加它们。如果引用表删除了一行(或更新了引用字段)，则需要完全扫描引用表以级联删除，或确保没有行引用已删除的行。

---

如果您的 id 字段的分布非常偏斜，增加该列的统计信息可能会有所帮助。

如果统计数据设置为 100，那么将记录 100 个最常见的 ID(来自样本)及其频率。假设它覆盖了大约 50% 的表，剩下 2 到 350 万行，PostgreSQL 将假设这些行平均分布在您的其他 8900 个 ID 中， 或每次大约 250 到 400 次。

如果统计数据增加到 1000，并且前 1000 个 id 覆盖了你 95% 的行，PostgreSQL 将假定不在你的 1000 个最常见列表中的 id 将分别出现大约 30 到 40 次。

估计值的变化会影响所选的查询计划。如果查询模式更频繁地选择不常找到的 ID，PostgreSQL 将高估找到这些 ID 的次数。

存储这么多最频繁的值会产生性能成本，因此您确实需要支持查询计划分析以确定您是否获得了净 yield 。