4 ms·

The table of times notes: > The shortest path query was not tested for MongoDB or PostgreSQL since those queries would have had to be implemented completely on

The table of times notes: > The shortest path query was not tested for MongoDB or PostgreSQL since those queries would have had to be implemented completely on the client side for those database systems. I can't speak for Mongo, but I imagine the shortest path query could be implemented as a recursive CTE or a sproc in Postgres, which would execute server side. It might be a bear to write, and it might be slow, but it should be possible.

janemanos 9y ago
If you know how to write the shortest path query for Postgres, team ArangoDB would be happy to include it into the next update
- lebotski 9y ago
  https://stackoverflow.com/questions/6873772/sql-postgres-shortest-path-in-graph-recursion https://stackoverflow.com/questions/6873772/sql-postgres-sho...
- tankenmate 9y ago
  Not exactly what you are asking for but this sits on top of PostgresQL and uses non-standard indexing to improve graph queries. https://github.com/bitnine-oss/agens-graph https://github.com/bitnine-oss/agens-graph
devbug 9y ago
I recently used RCTEs in a production environment to operate on reasonably large graphs. We eventually moved to an in memory solution built on top of ETS for various reasons, but performance was not a deciding factor (at least as much as you would think); Postgres handled our queries well beyond expectation, even with heavy factoring into functions. It's definitely not slow. The largest burden was on development and maintenance. Iterating algorithms and queries powered by RCTEs (and functions) on a changing schema is not scaleable (in effort), at least with the traditional migration scripts approach to upgrades and rollbacks. If you do want go this route, you need to change how you ship those functions and queries. We theorized that shipping them as part of the application and performing necessary migrations behind-the-scenes would have drastically reduced the maintenance burden. We also considered composing queries completely dynamically and fully leveraging our language (Elixir) to provide a toolbag of functions that aren't functions as far as Postgres was concerned. In either case, the hassle of versioning functions and queries would no longer get in the way iteration.

janemanos 9y ago

If you know how to write the shortest path query for Postgres, team ArangoDB would be happy to include it into the next update

lebotski 9y ago
https://stackoverflow.com/questions/6873772/sql-postgres-shortest-path-in-graph-recursion https://stackoverflow.com/questions/6873772/sql-postgres-sho...
tankenmate 9y ago
Not exactly what you are asking for but this sits on top of PostgresQL and uses non-standard indexing to improve graph queries. https://github.com/bitnine-oss/agens-graph https://github.com/bitnine-oss/agens-graph

devbug 9y ago

I recently used RCTEs in a production environment to operate on reasonably large graphs. We eventually moved to an in memory solution built on top of ETS for various reasons, but performance was not a deciding factor (at least as much as you would think); Postgres handled our queries well beyond expectation, even with heavy factoring into functions. It's definitely not slow. The largest burden was on development and maintenance. Iterating algorithms and queries powered by RCTEs (and functions) on a changing schema is not scaleable (in effort), at least with the traditional migration scripts approach to upgrades and rollbacks. If you do want go this route, you need to change how you ship those functions and queries. We theorized that shipping them as part of the application and performing necessary migrations behind-the-scenes would have drastically reduced the maintenance burden. We also considered composing queries completely dynamically and fully leveraging our language (Elixir) to provide a toolbag of functions that aren't functions as far as Postgres was concerned. In either case, the hassle of versioning functions and queries would no longer get in the way iteration.