Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep graph in Ram #2535

Open
esdras-kid opened this issue Jul 28, 2023 · 3 comments
Open

Keep graph in Ram #2535

esdras-kid opened this issue Jul 28, 2023 · 3 comments

Comments

@esdras-kid
Copy link

To optimize performance for large graphs, I have some ideas that could potentially improve the process. Currently, with every call to pgRouting, there is a time overhead for loading the graph from the PostgreSQL database and building the Boost C++ graph structure internally before running the algorithm.

My idea is to explore two possible approaches:

Keep the Graph in RAM:

It is possible to load the entire graph from the PostgreSQL database into RAM and keep it there during the lifetime of the application or API. By doing so, subsequent calls to the routing algorithm can directly access the graph data in memory, significantly reducing the overhead of loading the graph from the database each time.

Generate Boost Graph Structure in RAM:

If keeping the entire graph in RAM is not feasible due to size constraints, another approach is to generate the Boost C++ graph structure directly in memory and cache it for subsequent algorithm calls.

@cvvergara
Copy link
Member

Hi @esdras-kid

The thought looks interesting, but with the experience with graphs "on real roadneworks":

  • The road network for a car
  • is different for a pedestrian
  • is different for a truck A that weight X
  • is different for a truck B with weight Y and height Z.
  • is different at different times of day

But there might be problems where the graph might be static for a long period of time.
We meet on gitter and discussions with all developers take place at discourse.osgeo.org (look for pgrouting-dev)

@robe2
Copy link
Member

robe2 commented Dec 7, 2024

thread on users was started about this topic - https://discourse.osgeo.org/t/graph-in-memory/111494

The jitter is also accessible via matrix https://matrix.to/#/#pgrouting:osgeo.org

@joto
Copy link

joto commented Dec 8, 2024

I can only second that original request. It seems to me a lot of use cases would benefit from a pre-built graph and it would somewhat close the huge performance gap between pgRouting and specialized routing engines.

And it really would become interesting if it would be possible to "prepare" graphs and then merge several of those graphs for each request. Then I could split the area of interest into tiles, generate a graph for each tile, and add an additional graph that only contains the interstate highways. When the query comes in, I merge the tiled graphs nearest the source and target, add the interstate overlay and run the query on that.

The largest problem might be where to store the "prepared" graph. But even if it is not possible to do that prepare for the whole database, just for a single session or transaction, it could be useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants