Graph in memory

pgRouting pgrouting-dev
,
2

@kikislater
There are a couple of things we changed in recent versions to reduce the impact of graph building and to store graphs in memory for more than one route use.

  1. In prior versions of pgrouting before 3.7, the graph was built essentially twice, first in boost and then copied over to C. @cvvergara can discuss this a bit more. She revised to build once without having to copy.

  2. Functions have been added I forget the version I think from pgrouting 3.4 on, you will find many permutations of like dijkstra that does multi start , multi stop
    So it builds the graph once and uses to compute several route requests.

I discuss this a bit in my video on PostGIS Day 2024

and Vicky gives many examples of this in her state of pgRouting 2023 FOSS4G talk

So those are all going kind of in that direction.

I don’t think it’s realistic to keep a graph in RAM for multiple function calls because first of all, if you have a large dataset, you are probably using different parts of the graph depending on queries you are doing, so trying to load the whole graph in memory will easily eat up your RAM.

Secondly the way PostgreSQL is built, you can’t just create a graph in memory once and some how allow other connections to use it. In theory you could maybe trick shared buffers to do it.

I think the best bet might be to create some kind of custom type that can save the boost graph in a table in a format more usable, but I think even then you run into issues with toast / detoasting that may just make being able to pull that graph from PostgreSQL storage not worthwhile.

@pramsey has more knowledge of inner workings of PostgreSQL so might have some ideas on how he invisions this would work.

1 Like