4 ms·

Hi! Thanks for taking the time to engage on HN. I have a couple of questions around this. Firstly, what happens to the performance when I have a sizeable resu

Hi! Thanks for taking the time to engage on HN. I have a couple of questions around this. Firstly, what happens to the performance when I have a sizeable resultset of set-valued data? I've seen similar ideas implemented in the past that look fine for the Movies and Actors or Books and Authors examples but fall apart badly when you query a number of fields (20+) that have sets within them, which can happen on say, a sizeable reference database of marketing information. Another question: How deep in the graph can I go, and how much circular reference protection is there? E.g. if I query Movie.actors.movies.actors? I'm interested in graph databases and data modeling and while it offers some convenience I'm always skeptical but hopeful (mostly from having lost a lot of hours) that these problems have been solved sufficiently to keep performance good in practical use cases.

RedCrowbar 5y ago
EdgeDB is graph-relational, not a pure graph database, and so the performance characteristics of traversing links are that of a relational JOIN. Which, of course, depends wholly on the size of each relation being joined. So, if you want to select the list of actors for _every_ movie in your database and there are lots of movies, it'd be a pretty expensive operation. If, on the other hand, you want to select some relationships on a handful of objects (or even just one), then it doesn't really matter that much how deep your link traversal is, because all of the steps would be fast index scans. > How deep in the graph can I go, As much as you want, though the path must be explicit, EdgeQL currently doesn't have any way to say "traverse link foo recursively".