Efficiently storing a directed graph

From: "Kelly Jones" <kelly(dot)terry(dot)jones(at)gmail(dot)com>
To: mysql(at)lists(dot)mysql(dot)com, pgsql-general(at)postgresql(dot)org, graphviz-interest(at)research(dot)att(dot)com, nmlug(at)nmlug(dot)org
Subject: Efficiently storing a directed graph
Date: 2008-03-01 21:09:45
Message-ID: 26face530803011309j2dd394b4o3a1b33dd3735b447@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I have a directed graph (nodes and edges) that I want to store
"efficiently": given two nodes, I want to quickly find the shortest
path between them. The graph is NOT acyclic (it's not a tree), is
fairly "sparse" (about 10000 edges for 2500 nodes), and changes
occasionally.

I know PostgreSQL/MySQL can store graphs (as one table of nodes and
one table of edges that reference the nodes), but I think finding the
shortest path between two nodes is quite inefficient that way.

I know PostgreSQL/MySQL have special "plugins" (like PostGIS for
PostgreSQL) for specific problems. Is there a directed graph plugin?

I'm not married to using SQL: are there other efficient solutions to
store directed graphs? Could I hack something up in Perl or Ruby and
then serialize my in-memory graph to a file (for efficient
saving/reloading)?

As a minor note, the nodes/edges will have (non-unique) names and
descriptions, and I want the ability to do fulltext searching on these
names/descriptions. However, this is less important than quickly
finding the shortest path between two nodes.

--
We're just a Bunch Of Regular Guys, a collective group that's trying
to understand and assimilate technology. We feel that resistance to
new ideas and technology is unwise and ultimately futile.

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter Brawley 2008-03-01 22:29:06 Re: Efficiently storing a directed graph
Previous Message Simon Riggs 2008-03-01 18:17:33 Re: multi-threaded pgloader needs your tests