sql - postgres 综合性能

Question

我一直注意到 Postgres (8.3) 中简单聚合性能的一些问题。问题是，如果我有一个由 (customer_id,order_id) 唯一的表(比如 200M 行)，那么查询 select customer_id,max(order_id) from larger_table group by customer_id 不仅仅是一个比执行以下操作的简单 Java/JDBC 程序慢一个数量级:

1) 初始化一个空的 HashMap customerMap(这将映射 id -> 最大订单大小)2)执行“select customer_id,order_id from larger_table”，得到一个流式结果集3) 遍历结果集，在每一行执行如下操作:

long id = resultSet.getLong("customer_id");
long order = resultSet.getLong("order_id");
if (!customerMap.containsKey(id)) 
    customerMap.put(id,order);
else 
    customerMap.put(id,Math.max(order,customerMap.get(id)));

这种性能差异是预期的吗？我不这么认为，因为我想上面的内容与内部发生的事情非常接近。是否有证据表明数据库存在错误/错误调整？

Answer 1

这可能是您的 work_mem 设置太低了。我会先检查一下。我最近被这个咬了。第二个最可能的问题是您缺少外键索引。

说明如下。

一般来说，只要数据库性能低于标准，就需要问几个问题:

1. 您使用的是最新版本吗？ 7.4 和 9.0 之间的每个小版本都带来了显着的性能改进——如果可以升级，建议升级。
2. 您是否根据实际数据运行基准测试？ PostgreSQL 的查询计划器会对同一张表中不同的数据或不同的数据量产生不同的计划。确保始终使用真实数据进行测试。
3. 您的 PostgreSQL 配置如何？ work_mem 设置开箱即用，我自己遇到过涉及 GROUP BY 的情况，它人为地选择了错误的计划，因为它根本不认为它有有足够的工作内存来对结果进行排序。
4. 您的 Java 代码是否与数据库在同一台机器上运行？否则，您看到的可能是计算机之间的差异，而不是方法之间的差异。
5. 您是否缺少索引？ PostgreSQL 不会自动为外键创建索引，只会为主键创建索引。我也被这个困扰过，但如果你四处搜索，你可以找到一个脚本来检测和添加丢失的外键索引。

在不检查查询计划的情况下，猜测 PostgreSQL 为给定查询选择的实现策略不是一个好主意。