能否通过PostgreSQL并行查询加速pgRouting部分运算？

为什么当前并行方案反而变慢？ #

• PostgreSQL内置并行的适配场景不匹配：PostgreSQL的并行查询是针对单条SQL内的扫描、聚合等算子做并行优化，比如并行扫表、并行计算聚合值，但你是批量调用pgr_dijkstra函数。即使标记函数为PARALLEL SAFE，数据库也只会在初始的数据扫描阶段（比如生成顶点对）使用多核，后续实际执行每个pgr_dijkstra调用时，无法将这些独立任务持续分配到不同核心，调度开销反而拖慢整体速度。
• 小规模数据的并行开销大于收益：你的顶点表仅730条记录、边表1100条，单次pgr_dijkstra计算耗时极短。此时创建并行进程、进程间通信、数据拷贝的开销，远超过并行计算节省的时间，导致总耗时增加。
• pgr_dijkstra本身的单线程限制：pgr_dijkstra是单线程实现的路径查找算法，PostgreSQL的并行机制无法将单个pgr_dijkstra调用拆分为多线程任务；而批量调用时，数据库的并行调度逻辑无法高效地将多个pgr_dijkstra实例分配到不同核心持续运行。

可行的提速方案 #

方案1：使用pgRouting原生全对最短路径函数 #

pgRouting提供了专门的全对最短路径实现，比如pgr_allPairsDijkstra，它内部做了算法优化（比循环调用单源单汇的pgr_dijkstra效率高得多），无需手动处理并行，是最优解。

示例代码：

SELECT * FROM pgr_allPairsDijkstra(
    'SELECT id, source, target, cost FROM edges', -- 替换为你的边表查询语句
    directed := true -- 根据你的图是否有向调整参数
);

方案2：外部脚本实现多进程并行 #

如果必须手动处理批量pgr_dijkstra调用，建议用外部脚本（如Python、Bash）启动多个独立的数据库会话，每个会话处理一部分顶点对，真正利用多核资源。

比如用Python的multiprocessing模块分块处理：

import psycopg2
from multiprocessing import Pool

def process_batch(start_ids):
    conn = psycopg2.connect("dbname=your_db user=your_user password=your_pwd")
    cur = conn.cursor()
    for start_id in start_ids:
        cur.execute("""
            SELECT * FROM pgr_dijkstra(
                'SELECT id, source, target, cost FROM edges',
                %s,
                (SELECT array_agg(id) FROM vertices)
            );
        """, (start_id,))
        # 按需处理查询结果，比如写入结果表或文件
        result = cur.fetchall()
    conn.commit()
    conn.close()

if __name__ == "__main__":
    # 获取所有顶点ID并分成4份（可根据CPU核心数调整）
    conn = psycopg2.connect("dbname=your_db user=your_user password=your_pwd")
    cur = conn.cursor()
    cur.execute("SELECT id FROM vertices")
    all_ids = [row[0] for row in cur.fetchall()]
    conn.close()

    batch_size = len(all_ids) // 4
    batches = [all_ids[i:i+batch_size] for i in range(0, len(all_ids), batch_size)]

    with Pool(4) as p:
        p.map(process_batch, batches)

方案3：优化PostgreSQL并行查询的批量调用方式 #

如果坚持用数据库内置并行，可尝试用LATERAL关联顶点对的笛卡尔积，强制数据库生成并行执行计划，但这种方式在数据量较小时收益有限，仅推荐数据量较大时尝试：

SELECT *
FROM vertices s
CROSS JOIN LATERAL (
    SELECT * FROM pgr_dijkstra(
        'SELECT id, source, target, cost FROM edges',
        s.id,
        t.id
    )
) p
CROSS JOIN vertices t
WHERE s.id != t.id;

执行前可调整max_parallel_workers_per_gather参数（比如设为4），让数据库分配更多并行进程处理任务。

内容的提问来源于stack exchange，提问作者theTruthIsOutThere