PostgreSQL - 为什么对大型数据集的一些查询如此缓慢答案

【问题标题】：PostgreSQL - Why are some queries on large datasets so incredibly slowPostgreSQL - 为什么对大型数据集的一些查询如此缓慢
【发布时间】：2011-02-21 04:39:03
【问题描述】：

我经常在两个大型数据集上运行两种类型的查询。它们的运行速度比我预期的要慢得多。

第一种是顺序扫描更新所有记录：

Update rcra_sites Set street = regexp_replace(street,'/','','i')

rcra_sites 有 700,000 条记录。 pgAdmin 需要 22 分钟！我编写了一个 vb.net 函数，它遍历每条记录并为每条记录发送一个更新查询（是的，700,000 个更新查询！），它运行的时间不到一半。嗯……

第二种是简单的更新关系，然后是顺序扫描：

Update rcra_sites as sites 
Set violations='No' 
From narcra_monitoring as v 
Where sites.agencyid=v.agencyid and v.found_violation_flag='N'

narcra_monitoring 有 1,700,000 条记录。这需要 8 分钟。查询规划器拒绝使用我的索引。如果我从 set enable_seqscan = false; 开始，查询会运行得更快。我希望查询规划器能完成它的工作。

我有适当的索引，我已经抽真空并分析过了。我优化了我的 shared_buffers 和 effective_cache_size，因为我有 4GB，所以我知道使用更多内存。我的硬件非常好。我在 Windows 7 上运行 v8.4。

PostgreSQL 就这么慢吗？还是我还缺少什么？

【问题讨论】：

我建议发布EXPLAIN的结果（也可能是EXPLAIN ANALYZE），可能会有专家注意到的细节。
你应该发布你的架构、索引，并确保你的表是ANALYZEd。

标签： postgresql optimization query-optimization

【解决方案1】：

与 seq_page_cost 相比，可以尝试降低 random_page_cost（默认值：4）：这将通过使由索引驱动的随机访问更具吸引力来减少规划者对 seq 扫描的偏好。

要记住的另一件事是，MVCC 意味着更新一行是相当昂贵的。特别是，更新表中的每一行需要将表的存储量翻倍，直到它可以被清理。因此，在您的第一个查询中，您可能想要限定您的更新：

UPDATE rcra_sites Set street = regexp_replace(street,'/','','i')
                  where street ~ '/'

（afaik postgresql 不会自动抑制更新，如果看起来您实际上并没有更新任何内容。Istr 在 8.4（？）中添加了一个标准触发函数来允许您这样做，但最好是在客户端解决它）

【讨论】：

这些设置默认被注释掉了。我将 random_page_cost 更改为 2.0，将 seq_page_cost 更改为 3.0。查询规划器现在决定使用这两个索引。好的！是的，我应该更频繁地更新记录，但在许多情况下，我确实在更新所有行。查询时间现在减少到 6 分钟。但这对我来说似乎仍然太长了。
设置 seq_page_cost 高于 random_page_cost 对我来说感觉不对，但如果它对你有用....更新大部分表的缓慢是让并发事务能够访问旧版本的成本进行更新时的行数。其他数据库的工作方式不同。例如，如此大的更新可能会锁定整个表或耗尽其他系统中的撤消/重做空间。抱歉，我想不出还有什么可以帮上忙的……

【解决方案2】：

更新行时，会写入新的行版本。

如果新行不适合同一个磁盘块，则需要更新指向旧行的每个索引条目以指向新行。

需要更新的不仅仅是更新数据的索引。

如果您在rcra_sites 上有很多索引，并且只有一两个经常更新的字段，那么您可以通过将经常更新的字段分离到自己的表中来获得收益。

您还可以将fillfactor 百分比降低到其默认值 100 以下，这样某些更新可能会导致新行写入同一块，从而导致指向该块的索引不需要更新。

【讨论】：