Performance Postgres中非常慢的位图堆扫描

我有以下包含交通测量数据的简单表格：

CREATE TABLE "TrafficData"
(
  "RoadID" character varying NOT NULL,
  "DateID" numeric NOT NULL,
  "ExactDateTime" timestamp NOT NULL,
  "CarsSpeed" numeric NOT NULL,
  "CarsCount" numeric NOT NULL
)
CREATE INDEX "RoadDate_Idx" ON "TrafficData" USING btree ("RoadID", "DateID");

RoadID列唯一标识记录数据的道路，而DateID标识数据的一年中的某一天（1..365）——基本上是ExactDateTime的四舍五入表示

我大约有10万行；“RoadID”列中有1.000个不同的值，“DateID”列中有365个不同的值

然后运行以下查询：

SELECT * FROM "TrafficData"
WHERE "RoadID"='Station_1'
AND "DateID">20100610 AND "DateID"<20100618;

从“TrafficData”中选择*
其中“RoadID”='Station_1'
和“DateID”>20100610和“DateID”20100610:：numeric）和（“DateID”<20100618:：numeric））
->“RoadDate_Idx”上的位图索引扫描（成本=0.00..104.22行=2496宽度=0）（实际时间=1.637..1.637行=2016循环=1）
索引条件：（（（“道路ID”）：：text='Station_1'：：text）和（“日期ID”>20100610:：numeric）和（“日期ID”<20100618:：numeric））
总运行时间：2163.985毫秒

我的规格：

• 视窗7
• 博士后9.0
• 4GB内存

如果有任何有用的建议，我将不胜感激

• 4GB内存->6+您有100万条记录，这并不算大，但对于台式机来说，内存可能很重要。如果这不是桌面，我不知道你为什么会有这么小的内存
• 20100611和20100617之间的

  和“DateID”>20100610和“DateID”
  DateID

• 在DateID上创建索引
• 去掉字段名周围的所有双引号
• 将

  RoadID

  设置为文本字段，而不是VarChar

---

缓慢的部分显然是从表中获取数据，因为索引访问似乎非常快。您可以优化RAM使用参数（请参阅和），或者通过发出CLUSTER命令优化表中数据的布局（请参阅）

---

应该这样做。
除了Daniel的答案之外，集群操作是一个一次性的过程，可以重新排列磁盘上的数据。目的是从更少的磁盘块中获取2000个结果行
由于这是虚拟数据，用于找出如何快速查询它，我建议重新加载它，以更接近生成时加载方式的模式。我设想数据一次生成一天，这将有效地导致

DateID

和磁盘上的位置之间的强相关性。如果是这样，那么我要么按

DateID

进行集群，要么将测试数据拆分为365个单独的加载，然后重新加载
如果没有这些，并且随机生成数据，您很可能需要对磁头执行2000多次搜索

---

我还将检查您在Windows 7上运行的任何其他操作是否为您不需要的读取增加了时间，例如确保读取的块不包含病毒签名，或者同时执行自动计划的磁盘碎片整理（导致磁盘头几乎不可能接近上次读取数据库块时的位置）。
不幸的是，RAM升级不是一个选项。更多的RAM也不会有什么区别，因为索引文件已经“很小”足够加载到内存中。我还尝试了DateID-BETWEEN，遗憾的是没有区别。您还想在DateID上创建一个索引；请参阅Additions右侧，我在DateID上添加了一个索引。遗憾的是没有区别。这不是您正在使用的表，没有“StationId”column.Ah，是的；感谢您指出这一点。StationID==RoadID.My bad。我刚刚更改了表定义中的列名以使内容更直观，但未能更改查询定义和查询输出中的名称。我已更新了问题以包含正确的列名。您是否正在运行真空，或已禁用这是什么？我想它是开着的，但这只是一个没有更新的测试表：我创建了这个表，添加了100000.000虚拟行，现在正试图找到一种快速访问数据的方法。所以限制因素可能是你的硬盘或内存，但要搜索100万条记录并不是一个小数目。对于台式PC，我认为2secs是一个不错的响应时间，例如特别搜索两个where条件。我昨天尝试了这个方法，但在11小时后CLUSTER命令仍在运行时，我不得不放弃。Holla…也许一个简单的排序选择到另一个可能会更快？如果集群速度太慢，这似乎真的是一个io问题，而且数据似乎与索引完全不匹配。如果可以，请尝试这是在服务器类硬件上。。。

Bitmap Heap Scan on "TrafficData"  (cost=104.84..9743.06 rows=2496 width=47) (actual time=35.112..2162.404 rows=2016 loops=1)
  Recheck Cond: ((("RoadID")::text = 'Station_1'::text) AND ("DateID" > 20100610::numeric) AND ("DateID" < 20100618::numeric))
  ->  Bitmap Index Scan on "RoadDate_Idx"  (cost=0.00..104.22 rows=2496 width=0) (actual time=1.637..1.637 rows=2016 loops=1)
        Index Cond: ((("RoadID")::text = 'Station_1'::text) AND ("DateID" > 20100610::numeric) AND ("DateID" < 20100618::numeric))
Total runtime: 2163.985 ms

CLUSTER "TrafficData" USING "RoadDate_Idx";