1

好的,我很欣赏这个问题有点含糊,但是经过一天的谷歌搜索,我一无所获,任何帮助都将不胜感激,我愿意尝试任何事情。

问题是我们有一个 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 秒内返回,我知道这不是直接比较,但想表明这不是磁盘性能问题。

所以问题是......有什么建议吗?我应该更改任何网络设置吗?我错过了什么?我不能提供太多关于数据库的信息,但这里有一个解释分析,它被混淆了......

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
4

1 回答 1

0

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

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

于 2011-03-24T18:14:30.570 回答