为什么任何pgr_ *路由功能都会基于启用了pgrouting的DB中的OSM数据永久使用

我使用osm2po 4.7.7将德国OSM数据集加载到了可填充的数据库中。一切正常，我通过它的config设置了osm2po，并且它的Java部分像魅力一样工作。

我导入了* _2po_4pgr表，没有任何问题。甚至* 2po_v表也被导入，尽管我并不完全了解该表的关系。

我执行了pgr_createTopology函数，该函数运行了一段时间（12000秒），同时计算了所有6m边。我以为这可以达成协议，但速度仍然令人难以忍受。

我想知道我是否忘记了什么。我当时正在考虑使用pgRouting而不是java库，但是目前它的性能方面还处于比较之中。

pgRouting性能的问题似乎是新的pgr_astar和pgr_dijkstra使用整个图形（如果有一个图形，则可以保证解决方案）。获得更好性能的简单解决方案是将使用的图形限制为较小的区域。它有自己的问题，例如有时它可能会创建无法解决的图形

 (SELECT ST_Expand(ST_Extent(geom_way),0.1) as box  FROM hh_2po_4pgr as l1 WHERE l1.source =7 OR l1.target = 12) 

在源和目标集合上创建BBOX，并将其扩展0.1度，然后在pgr_查询中使用相同的查询来限制图形大小

Dijkstra从1.2s到〜65ms

SELECT  seq, id1 AS node, id2 AS edge, g.geom_way as the_geom
    FROM pgr_dijkstra(
            'SELECT id, source, target, cost FROM hh_2po_4pgr as r, 
            (SELECT ST_Expand(ST_Extent(geom_way),0.1) as box  FROM hh_2po_4pgr as l1    WHERE l1.source =7 OR l1.target = 12) as box
            WHERE r.geom_way && box.box',
            7, 12, false, false
    ) as r INNER JOIN hh_2po_4pgr as g ON r.id2 = g.id ;

A *从2s到〜50ms

SELECT seq, id1 AS node, id2 AS edge, cost
    FROM pgr_astar(
           'SELECT id, source, target, cost, x1,y1,x2,y2 FROM hh_2po_4pgr as r, 
             (SELECT ST_Expand(ST_Extent(geom_way),0.1) as box  FROM hh_2po_4pgr as l1    WHERE l1.source =7 OR l1.target = 12) as box
            WHERE r.geom_way && box.box',
            7, 12, false, false
    );

osm2po用于将数据（芬兰最新）导入postgis表。将要点索引添加到geom_way列，并为数据库运行全真空分析。共享内存1G。工作存储器512M

我最后得出的结论是，最好将整个图形（包括索引）放在一个单独的表空间中，该表空间使用ramdisk永久驻留在内存中。

为了在Ubuntu 13.04上设置ramdisk，我使用了以下说明，并且必须说它运行良好（其中包括在重启/重启后将数据重新加载到内存中的说明）。

下周，我将介绍新的SSD（读取速度为1GB / s），并尝试比较性能。

据我所知，这是保持1M +行图永久可访问的唯一解决方案，因为发生了连续的随机读取。

使用本指南可以为空间数据库设置索引。这是要点：

 1. create indexes on ID, source and target columns.
 2. create index using GIST on geom column.
 3. vacuum
 4. cluster on geom column
 5. analyze

对于我的_4pgr和_vertex表，仅源和目标列在导入后具有索引（osm2po-core-5.1.0）。