performance - PSQL = 快速，远程 sql = v.slow

Question

好的，我明白这个问题有点含糊，但经过一天的谷歌搜索，我一无所获，我们将不胜感激，我愿意尝试任何事情。

问题是我们有一个 PostgreSQL 数据库，它在特定表中有大约 10-15 百万行。

我们正在根据表中的 DateTime 字段对所有列进行选择。没有连接，只有带有 where 子句的标准选择(时间 >= x 和时间 <= y)。字段上也有索引...

当我在本地机器上使用 psql 执行 sql 时，它运行了大约 15-20 秒，并带回了 50 万行，其中之一是一个文本字段，每行包含大量数据(一个程序堆栈跟踪)。当我们使用相同的 sql 并通过 Npgsql 或 Windows 上的 pgadmin III 运行它时，大约需要 2 分钟。

这让我认为这是一个网络问题。我在查询运行时检查了机器，它没有使用大量内存或 CPU，网络速度可以忽略不计。

我也阅读了 Postgres 站点上关于内存设置的建议。包括更新 shmmax 和 shmall。

它是 Ubuntu 10.04、PSQL 8.4、4GB RAM、2.8GHz Quad Xeon(虚拟但专用资源)。该机器也有它的 Windows 对应版本(2008 R2、SS2008)，但已关闭。使用具有相同模式和数据的 SS，查询在大约 10-15 秒内返回，我知道这不是直接比较，但想证明这不是磁盘性能问题。

所以问题是……有什么建议吗？是否有任何我应该更改的网络设置？我错过了什么吗？我不能提供太多关于数据库的信息，但这里有一个 EXPLAIN ANALYZE 被混淆了......

Index Scan using "IDX_column1" on "table1"  (cost=0.00..45416.20 rows=475130 width=148) (actual time=0.025..170.812 rows=482266 loops=1)
Index Cond: (("column1" >= '2011-03-14 00:00:00'::timestamp without time zone) AND ("column1" <= '2011-03-14 23:59:59'::timestamp without time zone))
Total runtime: 196.898 ms

Answer 1

尝试在 psql 中将 cursor_tuple_fraction 设置为 1，看看它是否改变了结果。如果是这样，那么与获得全部结果相比，优化者可能会根据仅获得前 10% 左右的结果来选择更好的计划。 Istr psql 使用游标逐段获取结果，而不是“firehose”executequery 方法。

如果是这种情况，它不会直接指向解决方案，但您需要调整您的规划器设置，至少如果您可以在 psql 中重现该行为，那么可能更容易看到差异和测试更改。